-
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
Tracking issue for --unit-graph #8002
Comments
cc me and @vlad20012
I think there are two different low-levels in play here. First, this exposes the command line flags we pass to {
// stuff here is specific to Cargo and can change.
"meta": {
"features": ["somefeat"],
"pkg_id": "my-package 0.1.0 (path+file:///path/to/my-package)",
"target": {
"src_path": "/path/to/my-package/src/lib.rs",
...
}
},
// stuff here is build-system independent
"cfg": ["feature=somefeat"],
"root": "/path/to/my-package/src/lib.rs",
} The biggest problem with this plan would be build-scripts. We can easily express the recipe for compiling build script. However, the bit about "run the excutble and append cfgs it prints to stdout to the next unit" would have to go to |
This is great stuff, thanks for doing this work!
I agree that it would be nice to not have to run two commands. I think
I totally understand why this would be a PITA, however it does seem weird to have an option to a command like
If you're going to ship it as stable then it needs to be stable. You've got a version in the output so presumably you could support
I think it's fair to punt on this for now. It's straightforward to detect build scripts with A couple of notes from looking at the unit graph output from one of my crates locally:
|
Implementation: #7977
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#unit-graph
Summary
The
--unit-graph
flag emits a JSON structure showing Cargo's internal unit graph.Unresolved issues
cargo metadata
(to get package names, for example). It seems a little silly to have to run two commands. Adding this tocargo metadata
I think will be hard from a UX standpoint. It would require a superset of all flags of all commands (for example,cargo check --profile=test
fundamentally changes things, so it would need to reproduce that flag). Every time I look at that, it seems really messy. There's also some flags like--target
that don't interact withcargo metadata
very well.check
and acheck
for a test. The serialize implementation forCompileMode
does not output the different kinds. Not sure how this should be displayed.The text was updated successfully, but these errors were encountered: