-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo-metadata doesn't track target-specific dependencies #4632
Comments
As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it. I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect? The team would be especially grateful if such a comment included details such as:
Thank you for contributing! (The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.) If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable! |
cargo-tree still needs this before it can stop using cargo-the-library. |
Add kind/platform info to `cargo metadata` This adds an array `"dep_kinds"` to the resolve nodes of the `cargo metadata` output. It looks something like this: ```javascript "resolve": { "nodes": [ "id": "cargo 0.39.0 (path+file:///Users/eric/Proj/rust/cargo2)", "deps": [ { "name": "bufstream", "pkg": "bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", "dep_kinds": [ { "kind": "dev", "target": null } ] }, { "name": "winapi", "pkg": "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", "dep_kinds": [ { "kind": null, "target": "cfg(windows)" } ] } ] ] } ``` This allows one to filter the graph based on the dependency kind and platform. I'm not completely confident that this is the right course, but I can't think of a better design. In particular, it seems a little strange to include all platforms, but features get filtered. This is probably not a problem in practice (one can use `--all-features` to ensure all features are shown for the top-level packages). Filtering out based on platform is very difficult, because you cannot determine from the resolve alone which nodes will be host vs target. That requires the entire Unit graph. We may expose the Unit graph in the future, but this seems like a useful and simple step. This is a draft because I wanted to discuss this before moving forward. I'd like to add some more tests. cc #4632. This doesn't filter based on target, but does expose the target names. As mentioned above, I don't think filtering is possible. cc #5583. This adds more information. Closes #3984. Closes #4631 (I think). cc @sfackler who filed some of these issues.
I'm going to close, as I think this is now implemented via the |
While the target configuration for a dependency is included in cargo-metadata's output (e.g.
cfg(windows)
), it's not all that easy to filter down to the dependencies that are enabled for a given target. It'd be nice if cargo-metadata could optionally perform the target-specific filtering.The text was updated successfully, but these errors were encountered: