Unnecessary cache invalidation when setting environment variables

[VivekPanyam]

Problem

When an environment variable is set in configuration, build scripts unnecessarily rerun in the following scenarios:

1. An env var defined in the configuration is explicitly set to the same value in the environment (e.g. FOO=BAR is set both in the env and in the config file)

$ cat .cargo/config.toml
[env]
FOO = "/some/path"

$ cargo build
$ export FOO="/some/path"
$ cargo build
$ # ^ Build scripts rerun

2. An env var is defined with force = true, but explicitly setting that environment variable causes build scripts to rerun

$ cat .cargo/config.toml
[env]
SOMETHING = {value = "./a/path", relative = true, force = true}

$ cargo build
$ export SOMETHING=asdf # any value
$ cargo build
$ # ^ Build scripts rerun

Steps

No response

Possible Solution(s)

No response

Notes

These cases were found when running cargo build from a process running under cargo run. The nested build had env vars in the config explicitly set in its environment. Removing these vars caused build scripts to not rerun and caches to be reused.

Version

cargo 1.70.0 (ec8a8a0ca 2023-04-25)
release: 1.70.0
commit-hash: ec8a8a0cabb0e0cadef58902470f6c7ee7868bdc
commit-date: 2023-04-25
host: x86_64-unknown-linux-gnu
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:OpenSSL/1.1.1t)
os: Ubuntu 20.04 (focal) [64-bit]

[weihanglo]

Good catch. Thanks for reporting this!

We should perhaps switch from std::env::var to Config::get_env and Config::env_config.

https://github.com/rust-lang/cargo/blob/3a34fca9ee0eeaf63357e89836a72b200553180f/src/cargo/core/compiler/fingerprint/mod.rs#L776-L784

---

@rustbot label +A-rebuild-detection +A-environment-variables -S-triage +S-accepted

[heisen-li]

@rustbot claim

[weihanglo]

See also #10358.

[heisen-li]

Sorry, did I make a mistake?

It seems to have nothing to do with environment variables. As long as cargo build is executed repeatedly, the build script will be run repeatedly.

[weihanglo]

Going to close this, as it is essentially #10358. I'll post an update there.