Skip to content
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 build plan generation (--build-plan) #5579

Open
jonas-schievink opened this issue May 27, 2018 · 8 comments

Comments

@jonas-schievink
Copy link
Member

commented May 27, 2018

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

This comment has been minimized.

Copy link
Member Author

commented May 28, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2018

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

@hobofan

This comment has been minimized.

Copy link

commented Nov 13, 2018

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

This comment has been minimized.

Copy link

commented Nov 13, 2018

@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.

@LukasKalbertodt

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2019

I'm not sure if it fits this issue, but using build plans broke for auto_impl. We execute cargo build -Z unstable-options --build-plan to get the build plan. Unfortunately between rustc 1.36.0-nightly (7158ed9cb 2019-05-15) and rustc 1.36.0-nightly (7d5aa4332 2019-05-16) that command started removing .rlib files from target/debug/deps.

To reproduce, just create a new library project, add an dependency, compile with cargo build, take a look at target/debug/deps to make sure it contains .rlib files and execute cargo build -Z unstable-options --build-plan. Now the files are gone.

Is that intended?

@jonas-schievink

This comment has been minimized.

Copy link
Member Author

commented Jun 5, 2019

Yeah, the build-plan integration test calls cargo --build-plan too and broke in a weird way due to this. I've opened #6954 a while ago because of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.