In short, setting emit_rerun_if_env_changed(false) on a cc::Build does not prevent the is_flag_supported method from printing rerun-if-env-changed directives.
Here's a quick hello world example:
Cargo.toml
[package]
name = "scratch"
version = "0.1.0"
edition = "2021"
[build-dependencies]
cc = "1.1.0"
That's maybe kinda a bug, since I expected to see nothing. It looks like CC_ENABLE_DEBUG_OUTPUT is hardcoded in a different place than the rest of the variables (which go through getenv). But the main bug I want to report is what happens if we add a call to is_flag_supported, like this:
BUG: Now a lot of rerun-if-env-changed directives are making it out, even though we set build.emit_rerun_if_env_changed(false) early on.
I think the cause of this is that is_flag_supportedcalls Build::new internally, and the inner Build doesn't inherit this setting. I'll open a PR with a targeted fix for this issue, but we might want to consider something that would make it harder for similar mistakes to come up in the future.
In short, setting
emit_rerun_if_env_changed(false)
on acc::Build
does not prevent theis_flag_supported
method from printingrerun-if-env-changed
directives.Here's a quick hello world example:
Cargo.toml
main.rs
foo.c
build.rs
If I run a verbose build and look at the
rerun-if-env-changed
directives, here's what I see:Now, if I add
build.emit_rerun_if_env_changed(false)
to build.rs, here's what I see:That's maybe kinda a bug, since I expected to see nothing. It looks like
CC_ENABLE_DEBUG_OUTPUT
is hardcoded in a different place than the rest of the variables (which go throughgetenv
). But the main bug I want to report is what happens if we add a call tois_flag_supported
, like this:build.rs
BUG: Now a lot of
rerun-if-env-changed
directives are making it out, even though we setbuild.emit_rerun_if_env_changed(false)
early on.I think the cause of this is that
is_flag_supported
callsBuild::new
internally, and the innerBuild
doesn't inherit this setting. I'll open a PR with a targeted fix for this issue, but we might want to consider something that would make it harder for similar mistakes to come up in the future.This came up while I was investigating https://github.com/BLAKE3-team/BLAKE3/issues/324 and https://github.com/BLAKE3-team/BLAKE3/pull/413, and I might file follow-up issues related to those.