cargo icon indicating copy to clipboard operation
cargo copied to clipboard

cargo doesn't rerun build scripts when RUSTC is changed

Open jyn514 opened this issue 2 years ago • 3 comments

Problem

The RUSTC env variable is provided to build scripts by cargo. According to the docs: https://doc.rust-lang.org/cargo/reference/build-scripts.html#rerun-if-env-changed

It is not necessary to use this for environment variables like TARGET that Cargo sets.

Cargo should rerun build scripts when rustc changes. I suspect this code needs to account for the path of the compiler, not just the version: https://github.com/rust-lang/cargo/blob/3bc0e6d83f7f5da0161ce445f8864b0b639776a9/src/cargo/core/compiler/context/compilation_files.rs#L569

See https://github.com/rust-lang/rust/pull/93723 for a reproduction, but it's not anywhere close to minimal.

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.59.0-beta.5 (5ad495c68 2022-01-25)

jyn514 avatar Feb 07 '22 02:02 jyn514

This is currently intentional behavior. There are situations where RUSTC changes, but we don't want that to trigger a full recompile. If one rustc emits the same version output as another, then cargo assumes they essentially behave the same, even if they are from different paths. I'm not sure this is something that can be changed without causing unwanted recompiles in some situations.

ehuss avatar Feb 27 '22 20:02 ehuss

Ok. Is it possible to document this somewhere? Maybe around https://doc.rust-lang.org/cargo/reference/build-scripts.html#rerun-if-env-changed ?

jyn514 avatar Mar 01 '22 15:03 jyn514

If one rustc emits the same version output as another, then cargo assumes they essentially behave the same, even if they are from different paths.

To be clear, the original bug in x.py was that it cached the path from the build script and would try to run that compiler on all subsequent builds, which broke because the target directory was deleted.

jyn514 avatar Mar 01 '22 15:03 jyn514