cargo: reintroduce feature options, as a means to provide input for the interpreter #14660
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
My plan was to have a global option on the rust module in the same format as the cargo cli. |
|
https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options
|
|
Yep, looks good. The remaining bit is to introduce parsing of the user's Cargo.toml files as well and handling of more sections like [lints]. I have some code in QEMU that can be integrated in the Cargo interpreter. EDIT: Hmm, not so good after thinking more about it. Left a lengthy comment there. |
This was referenced May 31, 2025
Without feature options there is no way for the superproject to reconcile differences between different invocations of dependency(). Reintroduce options as they were before afd8944 ("cargo: Fix feature resolution", Meson 1.7.0), but also "complete" the default_options provided by _do_subproject_cargo() with all the features that were enabled via Cargo.toml. Signed-off-by: Paolo Bonzini <[email protected]>
bonzini
force-pushed
the
cargo-feature-options-again
branch
from
913b226 to
4cb1068
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Without feature options there is no way for the superproject to reconcile differences between different invocations of
dependency(). Until something along the lines of #14639 is completed, this makes it almost impossible to rely on Meson's Cargo interpreter when you have more than onedependency()using Cargo subprojects.Reintroduce feature options as they were before afd8944 ("cargo: Fix feature resolution", Meson 1.7.0). However, the Cargo interpreter also "complete" the default_options provided by
_do_subproject_cargo()with all the features that were enabled via Cargo.toml. This is also useful for themeson/meson.buildfiles, which now have access to the set of enabled features.Note however that the generated
meson.buildfile is not independent of enabled features, because it still hardcodes the list of dependencies.