Open
Description
rustc
reads the MACOSX_DEPLOYMENT_TARGET
environment variable (and similar other *_DEPLOYMENT_TARGET
variables), and uses that value to determine (probably amongst other things) certain options for LLVM and the linker.
However, it seems like this environment variable is not tracked as an external dependency, meaning that changing it does not cause rustc
/cargo
to rebuild the target, as is otherwise expected when changing environment variables that modify compilation.
E.g. running the following code:
cargo clean
MACOSX_DEPLOYMENT_TARGET=12.0 cargo build
MACOSX_DEPLOYMENT_TARGET=13.0 cargo build
I expected to see this happen: The project was built twice.
Instead, this happened: The project was built once, and then the cache was used the second time.
Meta
rustc --version --verbose
:
rustc 1.76.0-nightly (2f8d81f9d 2023-11-21)
binary: rustc
commit-hash: 2f8d81f9dbac6b8df982199f69da04a4c8357227
commit-date: 2023-11-21
host: aarch64-apple-darwin
release: 1.76.0-nightly
LLVM version: 17.0.5
Activity
madsmtm commentedon Nov 23, 2023
I know that a crate can emit
cargo:rerun-if-env-changed=MACOSX_DEPLOYMENT_TARGET
in theirbuild.rs
to opt in to this behaviour, but I'm not sure that's enough if there are other cached crates in the dependency graph that may have been built with a different deployment target?Noratrieb commentedon Dec 4, 2023
This also affects other apple targets with their
*_DEPLOYMENT_TARGET
s. Looks like the relevant code should somehow add the env var tosess.parse_sess.env_depinfo
. I'm not sure what the nicest way to ensure that would be.cc @BlackHoleFox
MACOSX_DEPLOYMENT_TARGET
in build scripts rust-lang/cargo#13115--env-set
option #119926madsmtm commentedon May 3, 2024
I'll add that this also affects the environment variable
SDKROOT
16 remaining items