Tracking issue for build plan generation (--build-plan)

[jonas-schievink]

Implemented in #5301, Cargo gained the ability to produce a JSON build plan containing a list of commands that need to be executed to build a target.

The feature is currently unstable and requires a nightly Cargo release as well as the -Zunstable-options command line argument. This issue tracks its eventual stabilization.

This feature was originally requested in #3815 to facilitate Cargo's integration into other build systems.

[jonas-schievink]

A perhaps non-obvious use case of this: I was able to reimplement the compile-fail test functionality provided by compiletest-rs using the build plan to figure out how to compile an integration test: https://github.com/jonas-schievink/compile-fail

The benefit of this approach is that asking Cargo how to build a test is much more robust than building the rustc command line manually (essentially guessing how dependencies should be linked). This should fix practically every bug where compiletest-rs would break with an error like "multiple matching crates found".

[saleemrashid]

One complication is that the downstream build system needs to know how to use build scripts. Otherwise, the build plan will execute the build script, without passing the --cfg options to subsequent rustc invocations.

[saleemrashid]

Also, including the path to the dep-info file would be useful, as it is not as simple as changing the file extension to .d. Libraries prefix the artifacts with lib, but not the dep-info files.

[luser]

I don't know if there's a useful way to associate issues with a tracking issue in GitHub, but I filed: #5719

[hobofan]

I just learned about the --build-plan as I was looking to integrate it into a future version of cargo-nono.

One thing that was really surprising to me, that there hasn't been any discussions about the implications of build.rs output altering the build plan as far as I can tell. I feel like that if that factor is ignored it would give either give consumers of the build plan a false sense of security that the produced build plan is static and always acurate, or leave a significant feature with many crates using it up for reeimplementation by the build-plan consumers.

To me it seems like that is something at least worth discussing before this feature will be stabilized.

[denzp]

@hobofan Indeed, it's impossible to predict what build script will do. It can create some files, alter the rustc environment, or add link flags.

For my use case (experiments with advanced Docker building and caching), I've made a small binary that handles build script output with cargo's cargo::core::compiler::BuildOutput.

Probably build-plan could be improved in a way that build script invocation should be somehow grouped with the target crate's rustc invocation.