https://pantsbuild.org/ logo
#development
Title
# development
h

happy-kitchen-89482

02/13/2021, 6:35 PM
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

fast-nail-55400

02/13/2021, 6:54 PM
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

happy-kitchen-89482

02/13/2021, 7:07 PM
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

fast-nail-55400

02/13/2021, 8:22 PM
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

happy-kitchen-89482

02/13/2021, 9:03 PM
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

fast-nail-55400

02/13/2021, 9:13 PM
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

average-vr-56795

02/14/2021, 12:12 AM
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

happy-kitchen-89482

02/14/2021, 5:04 AM
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