relative target-dirs cause spurious rebuilds #1694
Comments
|
After some investigation I've found this to be a dupe of #497 |
|
Hm actually, I'm going to swap these around, so I'm going to reopen this (but a fix will be posted very soon). |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Jun 8, 2015
The method of creating package ids in Cargo means that all sub-crates of a main repo have the same package id, which encodes the path it came from. This means that if the "root crate" switches, the package id for all dependencies will change, causing an alteration in package id hashes, causing recompiles. This commit alters a few points of hashing to ensure that whenever a package is being hashed for freshness the *source root* of the crate is used instead of the root of the main crate. This cause the hashes to be consistent across compiles, regardless of the root package. Closes rust-lang#1694
bors
added a commit
that referenced
this issue
Jun 8, 2015
The method of creating package ids in Cargo means that all sub-crates of a main repo have the same package id, which encodes the path it came from. This means that if the "root crate" switches, the package id for all dependencies will change, causing an alteration in package id hashes, causing recompiles. This commit alters a few points of hashing to ensure that whenever a package is being hashed for freshness the *source root* of the crate is used instead of the root of the main crate. This cause the hashes to be consistent across compiles, regardless of the root package. Closes #1694
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you have two packages in a repo and wish to use shared target dirs to avoid rebuilds, you might use relative target-dir specs (one in each package) to do this by setting them to
../targetor something.This causes cargo to rebuild everything, probably because it sees the two target dirs as `/path/to/package_a/../target" and "/path/to/package_b/../target".
Right now you can workaround this by using absolute paths through the CARGO_TARGET_DIR environment var.
The text was updated successfully, but these errors were encountered: