alt Hacker NewsSimilar to make, it does mtime chronological comparison of dependencies with target to determinate if dependencies changed. This is just so flawed and simple to fool by operations on filesystem that do not change mtime (move, rename):
1) pick a source file and make a copy of it for for later 2) edit selected source file and rebuild 3) move the copy to it's original location 4) try to rebuild, nothing happens
Replies
By not tracking file metadata through an index file, mtime-only incremental build systems trade a lot of reliability for only slightly more simplicity. https://apenwarr.ca/log/20181113
Copy (1) and edit (2) both bump mtime, usually. It's not obvious that in the workflow you describe ninja is problematic, rather than the workflow itself (which is atypical).
My guess is that it's for drop-in compatibility with make.
There is (at least) one open issue about this - the solution/alternatives are not trivial:
mtime rebuild logic is half-baked even by 1970s standards.
Bazel and Shake avoid this class of bug with content hashes, so a rename, restore, or tar extract does not leave the build graph in a stale state. Speed matters, but not enough to bet your repo on timestamp luck.
[ninja author] I did some thinking about this problem and eventually revisited with what I think is a pretty neat solution. I wrote about it here: https://neugierig.org/software/blog/2022/03/n2.html