Now that the CI change is in, can someone with rust knowledge look at the caching in https://travis-ci.org/pantsbuild/pants/jobs/475173381 ? Specifically the “store build cache” bit at the end, which spends almost 4 minutes generating a new cache file, because of changes like this:

0.00s224.36schange detected (content changed, file is created, or file is deleted):
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/build/engine-5d2fe14247e645c3/output
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/.fingerprint/async_semaphore-4e42358ae7ab8343/lib-async_semaphore-4e42358ae7ab8343
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/.fingerprint/async_semaphore-4e42358ae7ab8343/lib-async_semaphore-4e42358ae7ab8343.json
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/.fingerprint/bazel_protos-169caa3f26a66671/build
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/.fingerprint/bazel_protos-169caa3f26a66671/build.json
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/.fingerprint/bazel_protos-32b020364d5e6dba/lib-bazel_protos-32b020364d5e6dba
/home/travis/build/pantsbuild/pants/src/rust/engine/target/release/.fingerprint/bazel_protos-32b020364d5e6dba/lib-bazel_protos-32b020364d5e6dba.json
...

Pretty sure this would be fixed by also caching a few paths the rust codegen we do depends on. I have decent ideas for this, and will happily experiment on Monday if @aloof-angle-91616 doesn't get to it by then. Basically, every path that we println as cargo rerun if changed, we should cache