https://pantsbuild.org/ logo
Join Slack
Powered by
Other than ~/.rustup, ~/.cargo and src/rust/engine...
# development
h
Other than ~/.rustup, ~/.cargo and src/rust/engine/target/, what else might I need to cache to prevent recompiles of rust code? I'm caching all of those but a rebuild of src/rust is still triggered (although not a rebuild of 3rdparty code)
f
Copy code
Cache hit occurred on the primary key Linux-cargo-2d8a03e3b927b43ef3be66d8e269421445c5265ccdc141995ba7b479f73a2341-baf3ca8bd24669a1db3e68e42d97300c2e3ec008a55a5509e18c63c86371e95c, not saving cache.
for “Post Cache Cargo” https://github.com/pantsbuild/pants/runs/1894209575?check_suite_focus=true#step:18:2 is it in fact saving the cache?
h
It is, ~/.cargo hasn't changed after the build, so it doesn't re-store it
That's all that means
And that I assume is why only the firstparty code is rebuilt, the 3rd party code is fulfilled from that cache
But I assumed caching 
src/rust/engine/target/
would take care of that, and apparently not
f
maybe dump the files going into the cache? (e.g. with 
find
) and then see if the same set of files is unpacked in the subsequent run? (assuming there is a way to make a file with the listing from the CI run into an easily-accessible “artifact” https://config.travis-ci.com/ref/job/addons/artifacts)
also. maybe verbose output for the cargo/rustc run to see if it will log why it is compiling something?
h
I printed out the du -h and it looks like all the dirs are restored correctly, at least by rounded sizes.
Verbose output is a good idea
f
also maybe check 
Cargo.lock
for any diff?
also given https://github.com/rust-lang/cargo/issues/4961#issuecomment-359189913, set env var 
RUST_LOG=info
and it should print out why it was invalidating
a
Cargo currently uses mtime as its cache key, and git doesn't preserve mtime on clone
So first party code will always currently re-compile because of this. There's an issue in 
cargo
to use content instead of mtime as the key, but it's a fairly big change
It's possible that you could hack together some kind of "record the mtime of files, and alter their mtime before building them" script if you wanted... (Or to make cargo do content-based caching, or to make a pants ruleset which can be smarter than cargo!)
Third party code will be being cached because the cache volume where they're stored will presumably preserve timestamps adequately
h
aha, that is exactly it. Thanks @average-vr-56795!
That would have taken me forever to figure out
OK this is not worth working around, it'll have to wait until Pants has Rust support, which can, a you say, be smarter than Cargo.
👍 1
Open in Slack
PreviousNext
Powered by