Clean RUST_TARGET_DIR when soroban rlibs change #4510
Merged
+2
−0
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.
It seems -- I'll use "seems" here because I am not 100% certain but this is congruent with my observations of errors so far -- that rustc and/or cargo don't do a good job of tracking the dependency of librust_stellar_core.a on the manually-provided soroban rlibs: that recompiling the soroban rlibs causes us to trigger a rebuild of librust_stellar_core.a but cargo and/or rustc frequently decides that "nothing changed in its dependencies" and so doesn't actually do any recompiling. Which means we can wind up with stale soroban bits in librust_stellar_core.a.
(It also "seems" like the stamp-file time tracking based on
touch
isn't reliably triggering a rebuild; this seems like it should never be true sincetouch
altersmtime
which is all thatmake
tracks, but I think I observed such a failure during debugging and it's harmless to remove-and-recreate the stamp-file just to be sure.)