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.,
Follow-up Comment #3, bug #19448 (project make):
Sorry, but you're incorrect about the way original UNIX make worked. In
fact, every version of make that I'm familiar with does and has always
considered equal timestamps as "up to date". The POSIX standard for make is
quite clear about this as w
Follow-up Comment #2, bug #19448 (project make):
I will disagree with the original poster. Make's job is to be conservative:
after typing "make", you should be able to count on it that everything is up
to date. If that invokes a bit of extra work, the lost CPU time is far
better than risking so
Follow-up Comment #1, bug #19448 (project make):
I'm going to disagree with the original submitter. Make should be
conservative: if it's not certain that a file is up to date, it should be
rebuilt.
In particular, in the absence of other information, equal timestamps should
be considered NOT up