On Mon, 2026-04-06 at 16:10 -0400, Ben Boeckel wrote: > On Mon, Apr 06, 2026 at 12:41:15 -0400, Paul Smith wrote: > > However, I can imagine a reason why timestamps are updated. If you > > don't update the timestamps, then every time you run make > > subsequently autoconf and automake will be re-run again > > Note that `ninja` has a `restat = 1` to support this pattern of not > updating timestamps when commands are rerun. The "last rerun" times > are stored in `.ninja_log` and used to avoid rerunning in this case. > I assume `gmake` could implement this in some way, but POSIX `make` > is probably a "no" for all practical purposes.
POSIX make requires that out-of-date decisions are driven by file modification time, and nothing else. GNU Make follows POSIX and uses the filesystem as the "database" of what has been updated. You're correct that it could curate a separate log (similar to what ninja does) and make smarter choices, at the expense of some complexity (for example, dealing with corrupted or partially-written log files, multiple instances of make running in parallel in the same directory, etc. etc.) In fact quite a long time ago there was a GSoC project to add such support to GNU Make, but it failed (I accept the blame for the failure since I wasn't able to provide the mentoring required). If I recall correctly the hope was to use an individual marker file (or, even a symlink at least on POSIX systems) for each target rather than maintaining a central log file with the associated issues. As Nick says you can get something "kinda-sorta" similar with "witness" files (I call these "sentinel" files but there's no one accepted term that I'm aware of). This does work, if you get it right, but there are some mildly annoying UI/QoI issues you have to be willing to live with.
