]> git.proxmox.com Git - cargo.git/commit - src/bin/cargo/commands/rustdoc.rs
Auto merge of #7977 - ehuss:unit-graph, r=alexcrichton
authorbors <bors@rust-lang.org>
Tue, 17 Mar 2020 14:06:50 +0000 (14:06 +0000)
committerbors <bors@rust-lang.org>
Tue, 17 Mar 2020 14:06:50 +0000 (14:06 +0000)
commit1fc0630da9dc4c0f18488d8ccffab920a928d1be
tree7d3554ecb5e855dd7b1468995e53562da00a1450
parent3d3921129d4a6e127da756b7a5332493e029aac3
parent4107872f58469cddf2132d4d176f35d4333c32b5
Auto merge of #7977 - ehuss:unit-graph, r=alexcrichton

Add unit-graph JSON output.

This adds a `--unit-graph` flag that will emit a JSON object of Cargo's internal build graph.  See unstable.md for more details.

The primary motivator is to provide an accurate picture of which features are set. With the new feature resolver it is not possible to properly represent the features in the `cargo metadata` structure, because features are no longer unified.  Also, features selected depend on the command, and exactly which packages are being built.  To handle that in `cargo metadata`, it would need to add a "mode" flag, and a superset of flags for all build commands (test, check, build, etc.). To me that seemed like a difficult path to take.

This may also be helpful for making visualizations of the true dependencies.  `cargo metadata` doesn't show the intra-package dependencies like build scripts or test units, and walking the `cargo metadata` graph correctly isn't always obvious.

This initial concept exposes almost all of the fields. That may be a little too much, but I imagine we could always trim it before stabilizing.  This structure also has a high risk of being unstable, since it has a good chance of changing form in the future.  I figure that can be addressed with documentation emphasizing that it may change and we may not always provide backwards-compatibility (though we will try if it is not too much burden).

This could also potentially be extended in the future to include things like artifact paths, or "freshness", if we'd like to.