cargo always rebuilds crates, even if source is unchanged

[Byron]

See subject. This also translates to dependencies that are local, causing two crates to be rebuilt even though indeed only one of them changed code (e.g. CLI uses LIB, and CLI source change causes LIB to be rebuilt as well for now reason, effectively doubling build time).

How to reproduce

The following shows how even simple crates will be rebuilt whenever cargo-build is invoked.

$ git clone https://github.com/Byron/yup-oauth2
$ cd yup-oauth2
$ cargo build
# The first build is fine
$ cargo build
# it will build the crate again, but shouldn't
$ cargo build
# repeat as often as you like, it will always rebuild

A more complex example

The following will cause two projects to be rebuilt, as they are dependent on each other and available locally.

$ git clone -b next https://github.com/Byron/google-apis-rs
$ cd google-apis-rs
$ git checkout e434563
$ cd gen/groupsmigration1-cli
$ cargo build
# this is the first build, expected ... 
$ cargo build
# and it keeps going, rebuilding API and CLI
$ cargo build 
# ...

Meta

➜  yup-oauth2 git:(next) cargo --version --verbose
cargo 0.2.0-nightly (0d75eb6 2015-05-07) (built 2015-05-10)

➜  yup-oauth2 git:(next) rustc --version --verbose
rustc 1.1.0-nightly (4b88e8f63 2015-05-11) (built 2015-05-12)
binary: rustc
commit-hash: 4b88e8f63eeaf557c916a0a1e73150b028c44c52
commit-date: 2015-05-11
build-date: 2015-05-12
host: x86_64-apple-darwin
release: 1.1.0-nightly

[emberian]

So, this is a problem with some libraries, but not most. PistonDevelopers/image also has this issue. I don't know what characterstic these share that causes the issue.

[Byron]

Hopefully someone will be able to reproduce this issue using the instructions provided in the ticket to get a handle on this bug. It has been on-off ever since ... sometimes it works, sometimes it doesn't. And if it doesn't, working with Rust becomes quite painful ... working with Alpha and pre-1.0 software and dependencies in general requires some pain resistance anyway, but if the basic toolset stops working correctly, it's hard to bare ;).

[alexcrichton]

@Byron can you check out the .fingerprint/*/dep-* files generated from cargo build? If they contain the string <quote expansion then this is probably a duplicate of serde-rs/serde#85

[Byron]

Using an older build's output that was still using serde marcros on nightly, I could confirm a somewhat broken fingerprint file similar to what was already shown here:

/Users/byron/Documents/dev/rust/yup-oauth2^@/Users/byron/Documents/dev/rust/yup-oauth2/target/debug/libyup_oauth2.rlib: src/lib.rs src/device.rs src/refresh.rs src/common.rs src/helper.rs <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion <quote\ expansion
[...]

Apparently serde/quasi/aster are indeed part of the issue, and considering how difficult it is to use compiler plugins right now, following the proposed path of using serde_codegen along with syntex seems to be the solution.

Using the yup-oauth2 syntex branch I was able to compile yup-auth2 without the cargo-issue mentioned here. The fingerprint file looked good as well.

/Users/byron/Documents/dev/rust/yup-oauth2^@/Users/byron/Documents/dev/rust/yup-oauth2/target/debug/libyup_oauth2.rlib: src/lib.rs /Users/byron/Documents/dev/rust/yup-oauth2/target/debug/build/yup-oauth2-26518666b2674b13/out/lib.rs
[...]

In other words: this doesn't seem to be a cargo issue at all, even though I wonder how it's possible to trick cargo into using file-names ... maybe it is just picking some particular AST node and displays it, without actually checking what it is ?

[alexcrichton]

Syntax extensions can register their own input files with the compiler so they're emitted into the .d files (dependency files) generated by the compiler, and this is a case where something may just be leaking in by accident. It sounds like this isn't a cargo issue, however, so I'm going to close this. Thanks for looking into it @Byron!