-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(env): cargo:rerun-if-env-changed
doesn't work with env configuration
#14027
Conversation
pub fn get_target_envs(&self) -> CargoResult<&BTreeMap<String, Option<OsString>>> { | ||
return Ok(self.crate_type_process.get_envs()); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels very brittle because any change to how we pass in environment variables automatically gets used as fingerprinting, rather than intentionally choosing what we fingerprint. Just to check to see if this is correct is requiring checking several other places.
In fact, I think this will cause every build to rebuild everything when using jobserver because I think we are capturing the env after that is configured and that env includes file descriptors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was overlooking that we aren't fingerprinting all of it, only what the user requests. So maybe its not all that of a problem?
8cd1417
to
e7897e3
Compare
.and_then(|opt| { | ||
opt.as_ref() | ||
.and_then(|os_str| os_str.clone().into_string().ok()) | ||
}) | ||
.or_else(|| env::var(key).ok()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it strange to fallback to env::var
if the envs[key]
is non-UTF8. Maybe we should call env::var_os
and deal with into_string
at the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I didn't consider using env::var_os
instead of env::var
because I wanted to minimize the impact of the change and avoid affecting other behaviors. If there is an up-to-date value in the current environment variable, then use envs.get(key); otherwise the previous env::var(key)
is still used.
It looks like the only difference between env::var
and env::var_os
is whether the environment variable is a valid Unicode.
.and_then(|os_str| os_str.clone().into_string().ok()) | ||
}) | ||
.or_else(|| env::var(key).ok()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iiuc on Windows, env::var
calls GetEnvironmentVariableW
which is case insensitive. Since we're recreating our own environment look up, should this matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a more in-depth study of windows, I'm very sorry.
Do you mean that you shouldn't use env::var
or env::var_os
to query environment variables? That doesn't seem to work : see: rerun_if_env_changes and rerun_if_env_or_file_changes
34a8fae
to
c93867a
Compare
What does this PR try to resolve?
Fixes #10358