> There's an inherent race condition in the way "make" handles timestamps. If
> you save a newer version of a file while make is running and is just compiling
> that input file, the change won't be picked up by subsequent runs of "make",
> and you'll be left with an out-of-date binary.
The traditional remedy for this potential race is to go and get a mug of
coffee, so that you aren't futzing with the source while it compiles.
Of course, make -k may reveal a dumb typo in a header that you fix in
time to watch later files compile without problem, then restart make so
as to sort out the files compiled before you did the fix. All the same,
you need only touch the corrected header just before re-running make to
avoid any problem.
I don't think make should be worried about this potential race; it's an
obvious case of user error with an easy discipline for the user to apply
to avoid any problems. It's a rough-and-ready tool for developers, with
no pretenses of being intended for use by those who don't think about
how their tools work.
Of course, if a file-system had a separate "up to date at" file-stamp,
that make can set (to the newest dependency's time-stamp) and later
read, or if make were to store this same datum in a separate database,
it would solve your problem. It would also make it possible to have
make rules that tentatively build the new file, compare to existing,
replace if (meaningfully) different but only revise "up to date at"
otherwise.
> I was thinking about it for a couple of days now whether it's a bug in gcc or
> make. gcc could be modified to touch back the object file to the timestamp
> when it started up, and that would protect against it. (It'd also need to
> write a temporary file and rename in the end, just in case it's interrupted -
> I'm not sure if it does this or not). However, this would then needed to be
> implemented in all compilers, and even in every one-off command that people
> use from Makefiles to create files (generated source code, translations
> updated with msgfmt, and a whole lot more). So I think this approach is not
> feasibe, and wouldn't be the right design.
As you note, every command that might be used in a make rule would need
to do this "right", which is a prohibitive requirement.
> As mentioned in #46193 comment 1, ideally rules should write the output to a
> temporary file and atomically rename.
Requiring every command that could be used as a make rule to abide by
this is, again, prohibitive. The same goes (with a bonus dose of AI
completeness) for requiring make to be able to work out how to amend
arbitrary commands so that their output goes somewhere different. In
some cases, a tool decides the name of its output files based on the
name of input files and has no way to over-ride that choice. In other
cases, the tool always write a file with the same name, no matter what
the inputs are. It just isn't a thing make can sensibly try to control.
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
