Cargo recompiles hyper and its dependencies every time even if nothing changed

[Boscop]

I have multiple crates that belong to the same workspace. Two of them depend on hyper.
Whenever I run 'cargo build' on one of these two, after I ran it on the other, it recompiles hyper and all its dependencies, even if NOTHING changed. Even if something had changed in my source, it wouldn't have to recompile hyper.
This is very frustrating because I often have to switch between the crates and it always takes multiple minutes to compile.
I use 'hyper = "*"' in both Cargo.toml files, and my Cargo.lock file only contains one version of hyper: 0.9.10. I'm also using Iron in one of them, which also uses this version of hyper.

What's worse is that I can't even run both crates at the same time sometimes, because it says "Blocking waiting for file lock on the git checkouts" even though the other crate is not compiling anymore but running already. But I need to run them at the same time because they are server and client and have to communicate.

I would really appreciate any help on this!

I already tried 'cargo clean', it didn't help..

[alexcrichton]

This definitely seems like a bug! Could you run with RUST_LOG=cargo::ops::cargo_rustc::fingerprint=info and gist the logs of a build where it recompiled but it shouldn't have?

[Boscop]

@alexcrichton Thanks. So for this test I first ran cargo run on the client, then on the server, which both use hyper and are part of the same workspace. Also both depend on yakshaver/core which is also part of the workspace.
Then I ran cargo run on the client again without having changed ANY source code or config. It rebuilt a lot (maybe all) of the dependencies incl. core (but not hyper this time):
http://dpaste.com/3KWQY9D
Then I ran cargo run on the server again:
http://dpaste.com/2TEJ1KS
It rebuilt the dependencies again, incl hyper, also core.
Summary: It gets a fingerprint error for all the crates for some reason. Why?

Also, I can't run client and server at the same time; when I try, I get Blocking waiting for file lock on the git checkouts on the second one, and it only starts running (= rebuilding everything and then running) after the first of the two finished running. This shouldn't happen either, since there is no git checkout happening!

[alexcrichton]

It looks like the reason for recompiling is "profile configuration has changed", do the two projects have different [profile] configurations?

[Boscop]

Ah yes! One had codegen-units = 4.
I removed it and now it doesn't happen anymore. Thanks so much!
But this still doesn't explain the message Blocking waiting for file lock on the git checkouts, right?(!)

And it's kinda weird that this leads to a recompile of everything.

Btw, in a third crate that belongs to the workspace I have panic = 'abort'. Because I have a specific thread running that writes backup to disk and I want to abort if it panics. But this different profile also leads to everything being recompiled when I switch to other crates in the workspace. Is there a way to avoid this? E.g. is it possible to specify in the code instead of in the profile that if this specific thread panics, it should abort?

EDIT: The message Blocking waiting for file lock on the git checkouts still prevents me from running both client and server simultaneously with cargo run.

[alexcrichton]

Blocking waiting for file lock on the git checkouts

Ah so this is actually a bug in Cargo that will be fixed by #3213

And it's kinda weird that this leads to a recompile of everything.

Unfortunately Cargo treats the entire [profile] section as opaque where any change requires a rebuild. Cargo should pull profiles from the workspace to prevent this surprising behavior, but that's also unfortunately a bug right now that it's not implemented :(

[Boscop]

So all sub crates will share / inherit the same profile from the workspace Cargo.toml?
Which bug number is it? (I would like to subscribe)

[alexcrichton]

Sure yeah, that's #3206

I think I'm actually going to close this in favor of that as I think it's sorted out, but thanks for the report!