-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix avoiding a rebuild when moving around a workspace #5669
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in rust-lang#5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717
r? @matklad (rust_highfive has picked a reviewer for you, use r? to override) |
@bors r+ |
📌 Commit 4be5a44 has been approved by |
bors
added a commit
that referenced
this pull request
Jun 29, 2018
Fix avoiding a rebuild when moving around a workspace There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in #5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717
☀️ Test successful - status-appveyor, status-travis |
bors
added a commit
that referenced
this pull request
Jun 29, 2018
Fix avoiding a rebuild when moving around a workspace This is a backport of #5669. There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in #5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717 r? @alexcrichton
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There's a case where Cargo will recompile a project even if the fingerprint
looks like it's fresh, when some output files are missing. This was intended to
cover the case where an output file was deleted manually or otherwise messed
with. The check here was a bit too eager, however. It checked not only the
actual output destination of the compiler but also the location that we hard
link the output file up to.
Due to recent changes in #5460 we don't always create the hard links for path
dependencies in the top-level dir, and this meant that if the library were
compiled and then tested later on the test may recompile the original library by
accident.
The fix in this commit is to cease looking for the hardlink if it exists or not.
This way we only check for the presence of the output file itself and only
recompile if that file is missing. The reason for this is that we
unconditionally relink files into place whether it's fresh or not, so we'll
always recreate the hard link anyway if it's missing.
cc rust-lang/rust#51717