Follow-up Comment #4, bug #19448 (project make):
I agree with Paul. GNU make and posix have long decreed that equal
timestamps of target and source imply up-to-dateness, and I would not seek to
change that. [Any change to that rule would lead successive invocations of
make (separated by, e.g., minutes) on a project that builds in under 1 second
to ALWAYS rebuild. That would be a disaster!]
My original (perhaps badly explained) point was supposed to relate to a
different issue. Let's define two terms to help make clear what I wanted to
say.
(1) Define "user-make-invocation" to mean the process of a user typing "make"
into a shell (or make being invoked by a script etc).
(2) Define "internal-make-invocation" to mean whatever process "make" has to
undergo internally when it spots that it has just updated one of the include
files of the current Makefile - and thereby realises that it must re-read in
the Makefile (and the updated include file) and start over "afresh" in
accordance with the present manual (which I support).
In the present implementation "internal-make-invocation" and
"user-make-invocation" are basically the same thing - though they don't have
to be in order to comply with the spec. So far as I understand,
"internal-make-invocation" is implemented by something almost equivalent to a
call to system("make [initialArgs]");
My point is supposed to be that end users (well, at least ones like me) would
like to be able to view "user-make-invocation" as a sort of "atomic"
predictable command that doesn't depend on timestamp resolution DURING THE
TIME IT RUNS -- in the same way as a single ordinary invocation of "make"
doesn't depend on timestamp resolution if there are no fancy autogenerated
inclusions. No matter how crappy your filesystem time resolution is, make is
clever enough to plan its build order before it builds the first file. Sure,
your crappy filesystem time resolution might cause you problems BETWEEN
"user-make-invocations" (fair enough) but it NEVER causes you problems DURING
a "user-make-invocation" if there are no fancy rebuilt includes. This is the
good thing about make.
Only if there are re-generated includes (or if the user recursive make) is
crappy time resolution exposed DURING a "user-make-invocation" - and this
itself is only because of the present blurring of (1) and (2).
OK - there is no way make can avoid exposing filesystem vagueries in the case
of recursive make - so we forget that issue.
But in-principle it would be possible (if very difficult!) to design a
clever make implementation that didn't expose timestamp resolution DURING
"user-make-invocation"s when using re-generated include files. This might
involve keeping a virutal filesystem of sorts in memory - one only needing to
store time-ording-stamps (not timestamps!) against each target generated by a
rule, so that subsequent inner re-execs of make could use this virtual
database to split ties on second or subsequent runs.
I don't think that would be anti POSIX spirit or letter - I think it would
actually support it all the better - as "user-make-invocations" would become
deterministic and not unpredictable.
With the present implementation, it is technically not possible to predict
the outcome of "make" on some Makefiles, even if you know the latency of the
filesystem and have full knowledge of timestamps before a single
"user-make-invocation" when regenerated includes are used. Sometimes the
outcome is just random, as my test example showed.
But it would be hard to fix this problem in the manner I have suggested, and
I would quite understand why nobody would want to code it! I've no clear
idea of how it could be done for "make -j 4" usage etc.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?19448>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
