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.