Fix avoiding a rebuild when moving around a workspace #5671
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
|
|
|
@bors: r+ |
|
📌 Commit 68572ee has been approved by |
|
⌛ Testing commit 68572ee with merge ecd127c71c1dfaa311b66cc88e51995e41000d6d... |
|
💔 Test failed - status-appveyor |
|
@bors: retry |
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
|
☀️ Test successful - status-appveyor, status-travis |
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this pull request
Jun 29, 2018
This pulls in rust-lang/cargo#5671. It should permit us to bootstrap from the new beta compiler successfully.
|
Ah, crud. @alexcrichton I guess my fix for linux for |
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Jun 30, 2018
…chton Update beta Cargo This pulls in rust-lang/cargo#5671. It should permit us to bootstrap from the new beta compiler successfully. r? @alexcrichton
moshg
pushed a commit
to moshg/rust-std-ja
that referenced
this pull request
Apr 4, 2020
This pulls in rust-lang/cargo#5671. It should permit us to bootstrap from the new beta compiler successfully.
moshg
pushed a commit
to moshg/rust-std-ja
that referenced
this pull request
Apr 4, 2020
…chton Update beta Cargo This pulls in rust-lang/cargo#5671. It should permit us to bootstrap from the new beta compiler successfully. 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.
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