Make build timestamp files robust to concurrent source modification. #22997
Conversation
…cation. Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`. Fix rust-lang#6518.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
(i checked as well that |
|
@pnkfelix |
|
Seems good to me, as long as it's sufficiently portable. |
|
@bors rollup |
|
@bors force |
…edits, r=nikomatsakis Make build timestamp files robust in face of concurrent source modification. Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`. Fix #6518.
|
Aw man, looks like I need to get more creative when subverting our build system! |
|
@alexcrichton you should still be able to touch the stamp files after the fact. I find it hard to imagine a work process you're doing now that would stop working ... well, except for the work process that involves racing with |
Make build timestamp files robust in face of concurrent source modification.
Strategy: If the end goal is to touch e.g.
stamp.std, then we first touchstamp.std.start_timebefore doing anything else. Then when the receipe finishes, we touchstamp.stdusing the timestamp fromstamp.std.start_timeas the reference time, and removestamp.std.start_time.Fix #6518.