You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looks like this is the key to what results Meson under BuildStream to try to contact to Internet (and failing) instead of just immediately complaining wrap is missing. The parameter is --wrap-mode=nodownload
Obviously we would prefer meson to behave in a --wrap-mode=nodownload manner in order to produce a more human readable failure, as this would communicate the problem more clearly to project authors.
However we cannot fix this without breaking cache keys.
The policy for changing cache keys is that it must be "buy in" so that cache keys don't change without explicit plugin configuration selected, but in this case it is annoying to have to buy into a behavior that should really be default.
What's more, I'm not sure that the meson plugin parsing additional configuration can modify %{meson-args} in an optional way without implicitly breaking cache keys (i.e. there would have to be some if statement inserted into the configure commands).
The only non-breaking way I can think of off the top of my head right now, is for downstream users to explicitly add --wrap-mode=nodownload to meson-global in the project.conf variables.
If meson wrap mode could be controlled with environment variables, we might be able to use that in conjunction with environment-nocache in order to set this up without affecting cache keys (although I haven't given this enough thought to be 100% confident that this would be correct).
The only non-breaking way I can think of off the top of my head right now, is for downstream users to explicitly add --wrap-mode=nodownload to meson-global in the project.conf variables.
Heh, ended up doing stumbling on this before even finding this issue. FYI we have the following MR atm in GNOME:
to ensure that you can actually easily change the value.
Good call, I'd expect the last argument to be honored so it should be fine to put it in meson-global as is, but should double check that this will work.
Good call, I'd expect the last argument to be honored so it should be fine to put it in meson-global as is, but should double check that this will work.
If this works, it would be a lot simpler to set up. Less moving parts. Still, cache keys change. IMHO the bad thing about cache keys is not the fact that cache keys change but that they have to consistently change for everyone. This is the case for freedesktop-sdk and gnome who junction this repo but not necessarily to projects pip installing the package. It's not great if it's possible for multiple developers building same project to get different cache keys.
Activity
gtristan commentedon Oct 8, 2023
This is an interesting class of bug.
Obviously we would prefer meson to behave in a
--wrap-mode=nodownloadmanner in order to produce a more human readable failure, as this would communicate the problem more clearly to project authors.However we cannot fix this without breaking cache keys.
The policy for changing cache keys is that it must be "buy in" so that cache keys don't change without explicit plugin configuration selected, but in this case it is annoying to have to buy into a behavior that should really be default.
What's more, I'm not sure that the meson plugin parsing additional configuration can modify
%{meson-args}in an optional way without implicitly breaking cache keys (i.e. there would have to be someifstatement inserted into the configure commands).The only non-breaking way I can think of off the top of my head right now, is for downstream users to explicitly add
--wrap-mode=nodownloadtomeson-globalin the project.conf variables.If meson wrap mode could be controlled with environment variables, we might be able to use that in conjunction with
environment-nocachein order to set this up without affecting cache keys (although I haven't given this enough thought to be 100% confident that this would be correct).nanonyme commentedon Jan 12, 2024
Yeah, I guess we might need to have something like
to ensure that you can actually easily change the value. I don't see any way to do this without breaking cache keys.
alatiera commentedon Mar 19, 2024
Heh, ended up doing stumbling on this before even finding this issue. FYI we have the following MR atm in GNOME:
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/2784
Good call, I'd expect the last argument to be honored so it should be fine to put it in
meson-globalas is, but should double check that this will work.nanonyme commentedon Mar 20, 2024
If this works, it would be a lot simpler to set up. Less moving parts. Still, cache keys change. IMHO the bad thing about cache keys is not the fact that cache keys change but that they have to consistently change for everyone. This is the case for freedesktop-sdk and gnome who junction this repo but not necessarily to projects pip installing the package. It's not great if it's possible for multiple developers building same project to get different cache keys.
meson-global: Add wrap-mode=nodownload
meson-global: Add wrap-mode=nodownload
meson-global: Add wrap-mode=nodownload
meson-global: Add wrap-mode=nodownload
meson-global: Add wrap-mode=nodownload
meson-global: Add wrap-mode=nodownload