cargo metadata doesn't indicate that feature-enabled transitive platform-specific deps are platform-specific
#9863
Labels
C-bug
Category: bug
Command-metadata
S-needs-design
Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Comments
illicitonion
added a commit
to illicitonion/cargo
that referenced
this issue
Oct 25, 2021
If e.g. an optional feature is only enabled on certain platforms, meaning a transitive dependency is only enabled on certain platforms, currently that information can't be worked out from the output of `cargo metadata`. With this change, when a dependency is configured for a specific platform, its dependencies are by default also configured for that specific platform, unless they explicitly have a different platform attached to them. This makes it easier to translate crates.io packages for building with non-cargo build systems, because this platform-specific behaviour of feature resolution is now observable in `cargo metadata`, rather than requiring those systems to track and re-implement feature resolution themselves with regard to platforms. Fixes rust-lang#9863.
epage
added
S-needs-design
github-merge-queue bot
pushed a commit
to bazelbuild/rules_rust
that referenced
this issue
May 8, 2024
The Cargo [Feature Resolver version 2](https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2) behavior is currently not supported by the `cargo metadata` sub command (rust-lang/cargo#9863) which `crate_universe` uses to determine the dependencies of a target, leading to inaccuracies when dependencies are introduced via feature resolution for a particular configuration. In #1710 functionality was added to use `cargo tree` to perform feature resolution for each supported platform. This change expands on this trick to collect dependency information at the same time and use that to determine whether or not to include optional dependencies located in standard `cargo metadata` output in the rendered Bazel targets. Non optional or `target.cfg` (conditional) dependencies behave as they did before this change. Implementation details: - `FeatureGenerator` was replaced by `TreeResolver` - Optional dependencies are now rendered as selects on explicit platforms. This will expand the size of `cargo-bazel-lock.json` files but is expected to be more correct.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
If on one platform a crate enables a feature which enables a transitive dependency, and on another it doesn't, there's no way to capture this from the output of
cargo metadata.Steps
cargo metadataorcargo metadata --filter-platform=x86_64-unknown-linux-gnu. In this crate,serde'sderivefeature is enabled forx86_64-apple-darwinbut not forx86_64-unknown-linux-gnu, which means it depends onserde-deriveonx86_64-apple-darwinbut not onx86_64-unknown-linux-gnu.serde-deriveshould be built onx86_64-unknown-linux-gnu.Possible Solution(s)
DepKindInfo.targetfor these dependencies, such that they can be identified as platform-specific--filter-platformfor a non-matching platform, we could omit these dependencies. That may require callers to runcargo metadatamultiple times and splice the results, which would be a bit unfortunate.Notes
Output of
cargo version:cargo 1.54.0 (5ae8d74b3 2021-06-22), alsocargo 1.56.0-nightly (f559c109c 2021-08-26)This issue makes it hard to translate crates.io packages for building with non-cargo build systems.
The text was updated successfully, but these errors were encountered: