Unexpected rebuild around std::option_env!() usage

[Guiguiprim]

A dependency that use std::option_env!() cause systematic rebuild.

In my case: the dependency is the crate obfstr since version 0.4.0. It tries to read OBFSTR_SEED that I do not define.

From a small investigation it looks like meta-data saved by rustc about environment variable dependency is different when build with cachepot. # env-dep:OBFSTR_SEED became # env-dep:OBFSTR_SEED= which I guess triggers the rebuild by cachepot because the variable is not defined and it was expected to be defined empty.

> cargo init test-proj
> cd test-proj
> cargo add obfstr # needs obfstr ~0.4.0

# First build without cachepot
> cargo run
> grep "env-dep" target/debug/deps/*.d
target/debug/deps/obfstr-fb744c55b2eda770.d:# env-dep:OBFSTR_SEED
> cargo run 
# no rebuild

# First build with cachepot
> export RUSTC_WRAPPER=cachepot
> rm -rf target
> cachepot --clear-cache # to be clean
> cargo run
> grep "env-dep" target/debug/deps/*.d
target/debug/deps/obfstr-fb744c55b2eda770.d:# env-dep:OBFSTR_SEED=
> cargo run 
# rebuild from obfstr crate

[Guiguiprim]

For the time being a working work-around is to empty define OBFSTR_SEED.

[Guiguiprim]

Related to #137

Once built with a value for the environment variable, changing the environment variable does trigger a rebuild, but the *.d is not updated (probably false cache reuse) and we are again in a systematic rebuild situation.

[drahnr]

Thank you for the report! @Xanewok iff you have the capacity to take a look, I won't get around to it until two weeks from now.