depfile generation always rewrites depfiles even for null builds

[raggi]

If you re-run cargo build, and cargo does no work because no dependencies were altered, the depfiles are still re-written.

Example (trace of open calls with creat/wr during a null build):

[pid 16425] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/release/.cargo-lock", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 3
[pid 16425] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/x86_64-unknown-fuchsia/release/.cargo-lock", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 4
[pid 16425] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/x86_64-unknown-fuchsia/release/logger.d", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 7
open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/x86_64-unknown-fuchsia/release/logger.d", O_RDWR) = 3
[pid 16433] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/release/.cargo-lock", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 3
[pid 16433] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/x86_64-unknown-fuchsia/release/.cargo-lock", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 4
[pid 16433] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/x86_64-unknown-fuchsia/release/logger.d", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 7
[pid 16433] open("/usr/local/google/home/raggi/fuchsia/out/release-x64/rust_targets/x86_64-unknown-fuchsia/release/logger-6d687d38d931a012.d", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 7

[alexcrichton]

Thanks for the report! To confirm though, did this show up high in profiles? I've personally found that running rustc -vV has been more expensive historically along with parsing the registry json, but I may be running on conveniently fast filesystems!

[raggi]

It's not so much about a profile issue from a perspective of the work that it does in and of itself, but the side effect that by updating the modification time of the files it can cause other work to happen that is unnecessary. As an example, we have a core io library called 'fdio' that has many dependents, it's depfile is rewritten many times during the build even though it's binary and the dependencies are never altered.

[alexcrichton]

Ah right yeah, that definitely makes sense! Especially for the mtime of these (which are public facing files) we should avoid touching them on noop builds