[bug #19448] Re-exec after include file rebuild is more dependent on filesystem timestamps than strictly necessary.

2007-04-27 Thread anonymous
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

[bug #19448] Re-exec after include file rebuild is more dependent on filesystem timestamps than strictly necessary.

2007-04-27 Thread anonymous
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

[bug #19448] Re-exec after include file rebuild is more dependent on filesystem timestamps than strictly necessary.

2007-04-27 Thread Paul D. Smith
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

[bug #19448] Re-exec after include file rebuild is more dependent on filesystem timestamps than strictly necessary.

2007-04-27 Thread Christopher Lester
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.,