Dependency crates are recompiled upon change in main crate

[davidbarsky]

I've noticed that when I’m only depending on modules from the standard library, my compile times are less than a second. Whenever I pull in a Cargo crate, my compile times shoot way up—up to 12 seconds per file change. Here's what I mean:

Small file change (adding print!("Hello, world!), no dependencies in Cargo.toml:

❯ time cargo build 
        0.06 real         0.04 user         0.02 sys

Fresh build, with Rustbox as the sole dependency:

❯ time cargo build
   Compiling termbox-sys v0.2.9
   Compiling rustc-serialize v0.3.19
   Compiling bitflags v0.2.1
   Compiling winapi-build v0.1.1
   Compiling semver v0.1.20
   Compiling libc v0.1.12
   Compiling num-traits v0.1.35
   Compiling winapi v0.2.8
   Compiling libc v0.2.15
   Compiling kernel32-sys v0.2.2
   Compiling rustc_version v0.1.7
   Compiling rand v0.3.14
   Compiling tempfile v2.1.4
   Compiling num-integer v0.1.32
   Compiling num-iter v0.1.32
   Compiling gag v0.1.9
   Compiling num-bigint v0.1.35
   Compiling num-complex v0.1.35
   Compiling num-rational v0.1.35
   Compiling num v0.1.35
   Compiling rustbox v0.8.1
   Compiling husk v0.1.0 (file:///Users/David/Developer/Rust/husk)
       12.89 real        25.87 user         1.87 sys

Adding a single print!("Hello!"); statement after the previous build:

❯ time cargo build
   Compiling winapi v0.2.8
   Compiling num-traits v0.1.35
   Compiling libc v0.2.15
   Compiling semver v0.1.20
   Compiling bitflags v0.2.1
   Compiling rustc-serialize v0.3.19
   Compiling winapi-build v0.1.1
   Compiling kernel32-sys v0.2.2
   Compiling rustc_version v0.1.7
   Compiling rand v0.3.14
   Compiling tempfile v2.1.4
   Compiling num-integer v0.1.32
   Compiling num-iter v0.1.32
   Compiling gag v0.1.9
   Compiling num-bigint v0.1.35
   Compiling num-complex v0.1.35
   Compiling num-rational v0.1.35
   Compiling num v0.1.35
   Compiling rustbox v0.8.1
   Compiling husk v0.1.0 (file:///Users/David/Developer/Rust/husk)
       12.64 real        22.99 user         1.24 sys

The project I’m working is small and open-source. I haven't gotten the opportunity to try to reproduce it on a another machine, so maybe this is a misconfiguration on mine?

Previous discussion was held here and here.

[davidbarsky]

Update, sorry: Here are the versions of Rust and Cargo:

❯ cargo --version
cargo 0.12.0-nightly (6b98d1f 2016-07-04

❯ rustc --version
rustc 1.11.0 (9b21dcd6a 2016-08-15)

Thinking it might be an issue with the nightly cargo version. Investigating.

[davidbarsky]

Removed all traces of Rust, reinstalled with installer. Same versions, issue still present.

[alexcrichton]

Hm so the problem here is that Cargo is rebuilding crates when it perhaps shouldn't. I unfortunately can't reproduce this locally, but could you gist the output of RUST_LOG=cargo::ops::cargo_rustc::fingerprint when it unnecessarily rebuilds?

[davidbarsky]

Oh man, thanks for the hint. I got it. Turns out:

1. I used Rustup, but removed it due to issues with racer. Switched to the plain old installer.
2. Did not change CARGO_HOME in my shell.
3. Cargo could not find the previous builds.

FWIW, here's the gist that demonstrates the issue.

I’m thinking I could try adding an output to cargo to alert the user that the previous build cache couldn't be found (if that wasn't added as part of incremental compilation...).

[alexcrichton]

Ah ok, good to hear!

In that case I'm going to close this in favor of #2904 which is also about better diagnostics for why something is rebuilt, perhaps we can continue discussion there?

[davidbarsky]

Sure, sounds great!