Tracking issue for build plan generation (--build-plan) #5579
Comments
|
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". |
|
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 |
|
Also, including the path to the dep-info file would be useful, as it is not as simple as changing the file extension to |
matklad
added
the
C-tracking-issue
|
I don't know if there's a useful way to associate issues with a tracking issue in GitHub, but I filed: #5719 |
|
I just learned about the 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. |
|
@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 Probably |
|
I'm not sure if it fits this issue, but using build plans broke for To reproduce, just create a new library project, add an dependency, compile with Is that intended? |
|
Yeah, the |
|
ExamplePS D:\usr\Documents\Code\Rust\crafting-compilers> cargo +nightly clean
PS D:\usr\Documents\Code\Rust\crafting-compilers> cargo +nightly build -Z unstable-options
Compiling memchr v2.2.1
Compiling winapi-x86_64-pc-windows-gnu v0.4.0
Compiling lazy_static v1.4.0
Compiling winapi v0.3.8
Compiling proc-macro2 v1.0.5
Compiling unicode-xid v0.2.0
Compiling syn v1.0.5
Compiling autocfg v0.1.6
Compiling regex-syntax v0.6.12
Compiling cfg-if v0.1.10
Compiling libc v0.2.62
Compiling log v0.4.8
Compiling ucd-trie v0.1.2
Compiling serde v1.0.101
Compiling unic-char-range v0.9.0
Compiling ryu v1.0.0
Compiling unic-common v0.9.0
Compiling fnv v1.0.6
Compiling maplit v1.0.2
Compiling deunicode v0.4.3
Compiling itoa v0.4.4
Compiling humansize v1.1.0
Compiling percent-encoding v2.1.0
Compiling unicode-segmentation v1.3.0
Compiling glob v0.3.0
Compiling thread_local v0.3.6
Compiling crossbeam-utils v0.6.6
Compiling num-traits v0.2.8
Compiling num-integer v0.1.41
Compiling pest v2.1.2
Compiling unic-char-property v0.9.0
Compiling unic-ucd-version v0.9.0
Compiling slug v0.1.4
Compiling heck v0.3.1
Compiling crossbeam-channel v0.3.9
Compiling unic-ucd-segment v0.9.0
Compiling quote v1.0.2
Compiling pest_meta v2.1.2
Compiling bstr v0.2.8
Compiling parse-zoneinfo v0.2.0
Compiling globset v0.4.4
Compiling winapi-util v0.1.2
Compiling time v0.1.42
Compiling same-file v1.0.5
Compiling chrono v0.4.9
Compiling walkdir v2.2.9
Compiling chrono-tz v0.5.1
Compiling ignore v0.4.10
Compiling pest_generator v2.1.1
Compiling globwalk v0.7.1
Compiling serde_derive v1.0.101
Compiling pest_derive v2.1.0
Compiling serde_json v1.0.41
Compiling toml v0.5.3
Compiling tera v1.0.0-beta.18
Compiling tinyc_grammar v0.1.0 (D:\usr\Documents\Code\Rust\crafting-compilers\crates\grammar)
Compiling tinyc_lexer v0.1.0 (D:\usr\Documents\Code\Rust\crafting-compilers\crates\lexer)
Finished dev [unoptimized + debuginfo] target(s) in 1m 05s
PS D:\usr\Documents\Code\Rust\crafting-compilers> cargo +nightly build -Z unstable-options
Finished dev [unoptimized + debuginfo] target(s) in 0.17s
PS D:\usr\Documents\Code\Rust\crafting-compilers> cargo +nightly build -Z unstable-options --build-plan > $null
PS D:\usr\Documents\Code\Rust\crafting-compilers> cargo +nightly build -Z unstable-options
Compiling lazy_static v1.4.0
Compiling unicode-xid v0.2.0
Compiling regex-syntax v0.6.12
Compiling autocfg v0.1.6
Compiling cfg-if v0.1.10
Compiling ucd-trie v0.1.2
Compiling unic-char-range v0.9.0
Compiling maplit v1.0.2
Compiling fnv v1.0.6
Compiling unic-common v0.9.0
Compiling deunicode v0.4.3
Compiling itoa v0.4.4
Compiling percent-encoding v2.1.0
Compiling humansize v1.1.0
Compiling unicode-segmentation v1.3.0
Compiling glob v0.3.0
Compiling thread_local v0.3.6
Compiling crossbeam-utils v0.6.6
Compiling unic-char-property v0.9.0
Compiling pest v2.1.2
Compiling unic-ucd-version v0.9.0
Compiling slug v0.1.4
Compiling memchr v2.2.1
Compiling winapi-x86_64-pc-windows-gnu v0.4.0
Compiling proc-macro2 v1.0.5
Compiling log v0.4.8
Compiling libc v0.2.62
Compiling ryu v1.0.0
Compiling heck v0.3.1
Compiling num-traits v0.2.8
Compiling num-integer v0.1.41
Compiling unic-ucd-segment v0.9.0
Compiling crossbeam-channel v0.3.9
Compiling winapi v0.3.8
Compiling aho-corasick v0.7.6
Compiling bstr v0.2.8
Compiling quote v1.0.2
Compiling pest_meta v2.1.2
Compiling unic-segment v0.9.0
Compiling syn v1.0.5
Compiling regex v1.3.1
Compiling parse-zoneinfo v0.2.0
Compiling globset v0.4.4
Compiling winapi-util v0.1.2
Compiling time v0.1.42
Compiling same-file v1.0.5
Compiling walkdir v2.2.9
Compiling chrono v0.4.9
Compiling ignore v0.4.10
Compiling chrono-tz v0.5.1
Compiling pest_generator v2.1.1
Compiling globwalk v0.7.1
Compiling serde_derive v1.0.101
Compiling pest_derive v2.1.0
Compiling serde v1.0.101
Compiling serde_json v1.0.41
Compiling toml v0.5.3
Compiling tera v1.0.0-beta.18
Compiling tinyc_grammar v0.1.0 (D:\usr\Documents\Code\Rust\crafting-compilers\crates\grammar)
Compiling tinyc_lexer v0.1.0 (D:\usr\Documents\Code\Rust\crafting-compilers\crates\lexer)
Finished dev [unoptimized + debuginfo] target(s) in 1m 01sIs this intended, a bug, or an unfortunate requirement? This makes using |
|
I've reproduced @CAD97's issue. Could someone please investigate it? It's really blocking for IntelliJ-Rust |
Found out that `cargo build --build-plan` force next `build` command to recompile whole project (including dependencies). See rust-lang/cargo#5579 (comment). At this moment it is part of refresh, i.e. it is invoked on each `Cargo.toml` change, project reopening, etc. So this command is invoked quite frequently. It can be rather unexpected for large project to make full compilation after each project reopening
…ault Recently supported name resolution for included files uses `cargo build --build-plan` to fetch value of `OUT_DIR` environment variable (see #4542). Found out that `cargo build --build-plan` force next `build` command to recompile whole project (including dependencies). See rust-lang/cargo#5579 (comment). At this moment it is part of refresh, i.e. it is invoked on each `Cargo.toml` change, project reopening, etc. So this command is invoked quite frequently. It can be rather unexpected for large project to make full compilation after each project reopening So we decided to disable it by default until it will be fixed from cargo side or we'll find better way to get `OUT_DIR` value
4573: MACRO: disable name resolution for include with env("OUT_DIR") by default r=Undin a=Undin
Recently supported name resolution for included files uses `cargo build --build-plan` to fetch value of `OUT_DIR` environment variable (see #4542).
Found out that `cargo build --build-plan` force next `build` command to recompile whole project (including dependencies).
See rust-lang/cargo#5579 (comment).
At this moment it is part of refresh, i.e. it is invoked on each `Cargo.toml` change, project reopening, etc. So this command is invoked quite frequently.
It can be rather unexpected for large project to make full compilation after each project reopening
So we decided to disable it by default until it will be fixed from cargo side or we'll find better way to get `OUT_DIR` value
Co-authored-by: Arseniy Pendryak <[email protected]>
|
Note that the current conclusion in #7614 is to delete build plan support. If you're currently relying on build plans, please be sure to check that issue out and comment if you have thoughts! |
|
For crates with a build script, why not output a build plan entry that pipes an execution of the built script (with correctly set envvars) to a special cargo invocation that produces/executes the appropriate rustc invocation? |
|
On reflection, perhaps it should be specified that tools executing a Cargo build plan should monitor each step's stdout for messages that contain further build plan entries. The build plan for a dependency with a build script might then include two steps:
Consumers would then recursively execute build plans until no further steps are enqueued. |
ehuss
added
S-needs-design
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-optionscommand line argument. This issue tracks its eventual stabilization.This feature was originally requested in #3815 to facilitate Cargo's integration into other build systems.
The text was updated successfully, but these errors were encountered: