On Thu, 2014-08-21 at 13:57 -0700, Paul Eggert wrote: > David Boyce wrote: > > The obvious compromise would be to change the behavior only in the > > presence of the ".POSIX:" special target. > > We should limit ".POSIX" to what POSIX requires. Even if the ruling > stands POSIX won't require the HP-UX behavior, so ".POSIX" should be > independent of this issue. I pretty much agree with everything Paul says in this thread. First, I can't remember getting bug reports on GNU make that the current way it handles identical timestamps is a problem. I'm not saying that such a thing has never happened (my memory is not what it was for one thing) but certainly there have not been enough complaints to make this a known issue. And since this is just the kind of seemingly small change that will end up annoying and frustrating many people, I'm not excited about it. Similarly, unless POSIX mandates this change in behavior I'm not that excited about having the .POSIX target imply this change either: that seems to be mixing up too many obscure differences in a single flag. > It'd be OK to introduce a new special target to enable the HP-UX > behavior. .EQUAL_TIMES_ARE_OUT-OF-DATE, say. We could document the new > target next to .LOW_RESOLUTION_TIME, since they're related issues. The > new target could act like .LOW_RESOLUTION_TIME, except that it imposes > HP-UX rather than low-res behavior. I think something like this may be the way to go, but it might need to be more comprehensive than this even. Consider the Savannah bug https://savannah.gnu.org/bugs/index.php?40056 which complains about builds where some of the files live on filesystems that do support hires timestamps and some files do not. Despite the interesting review of the 10th grade concept of significant digits (*rolleyes*) I don't particularly care for the solution provided there: assuming that a subsecond value of 0 always means there is no subsecond resolution seems to me to be problematic. However, it needs to be considered carefully. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
