mirror of
https://github.com/rust-lang/cargo
synced 2024-10-02 05:53:53 +00:00
update comment based on further research
This commit is contained in:
parent
08843a0457
commit
b1fbafd066
|
@ -744,10 +744,23 @@ where
|
|||
return true;
|
||||
}
|
||||
};
|
||||
// Equal mtimes could mean that the input was changed in that same second,
|
||||
// but *after* the output was generated. So this means they are stale.
|
||||
// In theory, cargo is using nanosecond precision throughout so this
|
||||
// should not make a difference -- but it was necessary to fix #5918.
|
||||
|
||||
// Note that equal mtimes are considered "stale". For filesystems with
|
||||
// not much timestamp precision like 1s this is a conservative approximation
|
||||
// to handle the case where a file is modified within the same second after
|
||||
// a build finishes. We want to make sure that incremental rebuilds pick that up!
|
||||
//
|
||||
// For filesystems with nanosecond precision it's been seen in the wild that
|
||||
// its "nanosecond precision" isn't really nanosecond-accurate. It turns out that
|
||||
// kernels may cache the current time so files created at different times actually
|
||||
// list the same nanosecond precision. Some digging on #5919 picked up that the
|
||||
// kernel caches the current time between timer ticks, which could mean that if
|
||||
// a file is updated at most 10ms after a build finishes then Cargo may not
|
||||
// pick up the build changes.
|
||||
//
|
||||
// All in all, the equality check here is a conservative assumption that,
|
||||
// if equal, files were changed just after a previous build finished.
|
||||
// It's hoped this doesn't cause too many issues in practice!
|
||||
if mtime2 >= mtime {
|
||||
info!("stale: {} -- {} vs {}", path.display(), mtime2, mtime);
|
||||
true
|
||||
|
|
Loading…
Reference in a new issue