Command to run only build scripts

[matklad]

Hi!

This is a pre-RFC style issue just to write down some long-term thoughts.

The IDE support for rust progressed enough that build scripts need some special support. Specifically, for IDEs it would be useful if Cargo can just run the build scripts and compile proc-macros, without building any code. That is, do all the stuff for $host, and skip everything $target related. With this, IDE can provide full support for generated code and procedural macros, without requiring that the code itself builds (if it can also discover results of build-scripts, like the OUT_DIR).

In the ideal world, I think this should work like this:

cargo build --compile-time-deps # only stuff for $host is run
cargo run # guaranteed  to *not* build anything for $host 
cargo test # guaranteed  to *not* build anything for $host as well

I think we unfortunately can't do that now, as there's little separation between "stages" of dependencies, and, for example cargo run and cargo test might run build scripts slightly differently. This also seems to touch "build profile" and "build-deps features influcence the final artifact" problems.

[matklad]

cc @Undin

[matklad]

@vlad20012 pointed out that cargo check can act as a substitution for --compile-time-deps: it builds proc-macros and executes build scripts and, while it doesn't completely skip the $target code, it only checks it.

[simbleau]

I'm in favor of a cargo prep or cargo prep build. Simple and to the point - Run the build script exclusively.

Here's a simple, practical, graphics-related example why this needs to be implemented:

• User has a build script which compiles a GLSL Fragment shader (e.g. shader.frag) to SPIR-V and saves the binary output file (e.g. shader.frag.spv).
• User writes a new shader, and uses the output file (generated from the build script) in their graphics application: e.g. device.create_shader_module(&wgpu::include_spirv!("shader.frag.spv"))
• User is now confronted with an insurmountable compile error: couldn't read src/shader.frag.spv: No such file or directory (os error 2)rustc, because the build script has never initially generated this file yet, and it will refuse to compile.

In this example, the solution is to touch a file with the same name, for every new file. Or for example, have a custom make solution.

[trondhe]

I'm thinking of introducing Rust at work into an existing project using Cpp + Cmake. By using Corrosion to import the rust crate and Cxx to generate cpp source file bindings, such a command could then be run at cmake configure time such that they exist at build time.
I am not sure at all however if this is the right approach, but it seems somewhat reasonable at first glance.

[matklad]

The status quo today is that IDEs use this RUSTC_WRAPPER hack to shortcut the build process:

#9071 (comment)

Recently, it was found to cause problems. In particular, build scripts can use rustc not failing as a signal that a particular language feature is supported: dtolnay/anyhow#252, and that breaks if rustc is an always succeeding shim!

[epage]

Is there a reason that cargo check isn't sufficient for this compared to the cost of designing a while new feature just for these use cases?

[Undin]

just for these use cases

Remember that "these use cases" are about all main IDE solutions at this moment (either rust-analyzer or Rust plugin in IntelliJ ecosystem), so it affects quite a lot of Rust developers

[Veykril]

My RFC for this goes a bit into the usecases etc rust-lang/rfcs#3344
(Turns out I never linked this here)

But in short, IDEs really really want this because cargo check has downsides that we'd like to avoid (outlined in the linked RFC).

[epage]

Remember that "these use cases" are about all main IDE solutions at this moment (either rust-analyzer or Rust plugin in IntelliJ ecosystem), so it affects quite a lot of Rust developers

I raised it because there wasn't much talk of why that wasn't sufficient.

[jstarks]

I have a use case where we have tooling that scans generated code. We'd like this scan to be relatively cheap, but cargo check is quite expensive for our large project. It would be great if we could run code generation (by running all the build scripts in the workspace) without having to run all the Rust code through rustc as well. And all the conversation about breaking build scripts makes me nervous about trying to implement and maintain a RUSTC_WRAPPER.

[anforowicz]

Another scenario where it may be useful to ask Cargo run just the build script is integration with other, non-Cargo build systems. For example, Chromium uses GN/ninja-based build system and:

• Builds build scripts using GN (see rust_executable(_build_script_name) { ...} in build/rust/cargo_crate.gni here)
• Runs build scripts in a way that emulates Cargo behavior (e.g. setting the same environment variables that Cargo would set). As pointed out in https://crbug.com/364904747#comment3 this emulation is fragile. If Cargo supported running just the build script, then we would use this ability to run a custom build script (e.g. one that just dumps all environment variables it sees that are prefixed with CARGO_) to figure out how to emulate the environment in which Cargo runs build scripts. (I hope this captures the gist of this idea. /cc-ing @danakj in case I got some of this wrong.)