search

paritytech / cachepot

cachepot is `sccache` with extra sec, which in turn is `ccache` with cloud storage
https://cachepot.cc
Apache License 2.0
171 stars 13 forks source link

Unexpected rebuild around `std::option_env!()` usage #166

Open Guiguiprim opened 2 years ago

Guiguiprim commented 2 years ago

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 commented 2 years ago

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

Guiguiprim commented 2 years ago

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.

drahnr commented 2 years ago

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.