sccache never has cache hits when invoked through cargo #193
Comments
|
We noticed this same regression when updating to Rust 1.20 in Firefox automation, but I haven't found time to track it down yet. |
|
Is that |
|
Yes. Empty main function. One dependency. Here is the Cargo.lock: |
|
I tried this locally and figured it out. Since cargo gained jobserver support, it now passes a |
…#193 Since cargo gained jobserver support it now passes a CARGO_MAKEFLAGS environment variable which is different for every build (it contains file descriptor numbers or semaphore values). sccache uses all environment variables starting with `CARGO_` as inputs to the hash key for Rust compilation so this broke things. I think it was mostly only a problem on Windows, where the values were semaphores. On POSIX platforms the values are file descriptors, which are probably likely to be the same between runs of cargo. This change also adds a test for compiling a simple Rust crate with cargo and verifying that we get a cache hit. I pulled in the `assert_cli` crate to write that test, which worked nicely.
…#193 Since cargo gained jobserver support it now passes a CARGO_MAKEFLAGS environment variable which is different for every build (it contains file descriptor numbers or semaphore values). sccache uses all environment variables starting with `CARGO_` as inputs to the hash key for Rust compilation so this broke things. I think it was mostly only a problem on Windows, where the values were semaphores. On POSIX platforms the values are file descriptors, which are probably likely to be the same between runs of cargo. This change also adds a test for compiling a simple Rust crate with cargo and verifying that we get a cache hit. I pulled in the `assert_cli` crate to write that test, which worked nicely.
|
Thanks for the bug report! Knowing that this bug manifested with a basically-empty crate made it much easier to diagnose than trying to build all of Firefox. :) |
|
Just to be sure, since this is easy to reproduce, could you add test to prevent regression? There could be new env variable introduce in the future that is volatile and should trigger test failure. Also, is using all CARGO_ env variable as part of key input good design? Is it possible to identify a set of core variables and only relying on those? Basically I'm saying, instead of doing blacklisting, should we do whitelisting. Anyway, thanks for fixing. |
Yes, I did exactly that: sccache/tests/sccache_cargo.rs Line 48 in 2d9bdc1 Not having that kind of test in the first place was a pretty big oversight on my part!
The unfortunate thing here is that Rust code can use any environment variable via the |
I have Rust 1.22 nightly installed. I installed sccache with
cargo install sccache(sccache 0.2.1). I followed instruction to set upRUSTC_WRAPPER=sccache. When building Rust project, no matter how many time I rebuild, sccache never has cache hits. My OS is Windows 10.Here is an simple example. I create a snippet project with one dependency and no transitive dependency:
I run
cargo build -vseveral times and here is output:Notice I remove the compiled dependency before I run
cargo build, and the time spent is exactly same.Now if I directly run the first line
suddenly I start to get cache hits. So it looks like cargo is the culprit for the problem.
The text was updated successfully, but these errors were encountered: