cachepot
cachepot copied to clipboard
paritytech
Unexpected rebuild around `std::option_env!()` usage
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
For the time being a working work-around is to empty define OBFSTR_SEED.
Related to https://github.com/paritytech/cachepot/issues/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.
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.
