[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: POSIX ruling on up-to-date vs. identical timestamps

From: Paul Smith
Subject: Re: POSIX ruling on up-to-date vs. identical timestamps
Date: Sat, 23 Aug 2014 18:25:10 -0400

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 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]