Comments (4)
This is an interesting class of bug.
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).
from buildstream-plugins.
Yeah, I guess we might need to have something like
variables:
meson-wrap-mode: nodownload
meson-args: |
....
--wrap-mode=%{meson-wrap-mode}
to ensure that you can actually easily change the value. I don't see any way to do this without breaking cache keys.
from buildstream-plugins.
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
tomeson-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:
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/2784
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.
from buildstream-plugins.
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.
from buildstream-plugins.
Related Issues (20)
- `bst workspace open` dislikes git sources that have submodules HOT 6
- plugins/sources/git.py: Do not checkout submodules by default HOT 25
- Add plugins for handling meson subprojects HOT 11
- git plugin's track-tags option isn't enough for gnulib's git-version-gen HOT 4
- Complete git history of plugins is missing HOT 2
- Cargo plugin can't handle git sources HOT 2
- Cargo sources not successfully staged into sandbox HOT 6
- Cargo tracking has no tests
- Adapt the 'cargo' plugin to make better use of the YAML Node API
- Publish buildstream-plugins docs somewhere HOT 3
- autotools build-dir handling not compatible with relative conf-root
- https://apache.github.io/buildstream-plugins/ is pointing to old tag (1.91) instead current 1.95.1 HOT 1
- Drop {conf,cmake,meson}-extra HOT 2
- Get rid of tight ninja coupling of Meson element
- CMake FetchContent? HOT 1
- cargo: Generate a Cargo.lock if one wasn't found HOT 20
- Docker plugin unable to track any modern registries HOT 1
- Missing requirements for Docker source plugin
- docker: Does not support `project.refs`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from buildstream-plugins.