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

2014-08-26 Thread Keith Marshall
On 26/08/14 18:22, Eli Zaretskii wrote: >> Date: Tue, 26 Aug 2014 08:25:38 -0700 >> From: Paul Eggert >> Cc: Autoconf , Eric Blake , >> bug-make >> >> As far as Windows goes, NTFS file systems have 100 ns resolution, and >> FAT file systems are the joker as they have a 2-second resolution f

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

2014-08-26 Thread Keith Marshall
On 26/08/14 16:18, Paul Smith wrote: > Can't we just #define stat(_p,_b) _stat(_p,_b)? Not sure if that's > sufficient: I'm not overly familiar with the limitations on the POSIX > emulation functions in Windows. That's effectively what MinGW does anyway, (although it does it through an import lib

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

2014-08-26 Thread Eli Zaretskii
> Date: Tue, 26 Aug 2014 18:30:12 +0100 > From: Keith Marshall > CC: autoc...@gnu.org, ebl...@redhat.com, bug-make@gnu.org > > > FAT filesystems are hardly important these days. > > Except insofar as they tend to be prevalent on removable media devices, > such as USB flash drives; woe betide any

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

2014-08-26 Thread Eli Zaretskii
> Date: Tue, 26 Aug 2014 08:25:38 -0700 > From: Paul Eggert > Cc: Autoconf , Eric Blake , > bug-make > > As far as Windows goes, NTFS file systems have 100 ns resolution, and > FAT file systems are the joker as they have a 2-second resolution for > last-modified time. That's true, but F

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

2014-08-26 Thread Eli Zaretskii
> From: Paul Smith > Cc: egg...@cs.ucla.edu, autoc...@gnu.org, ebl...@redhat.com, bug-make@gnu.org > Date: Tue, 26 Aug 2014 11:18:35 -0400 > > > The main problem is that this requires to write a replacement 'stat' > > (not rocket science). > > Can't we just #define stat(_p,_b) _stat(_p,_b)? Not

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

2014-08-26 Thread Paul Eggert
Paul Smith wrote: It's trivial to determine the filesystem in POSIX via the device ID available from stat() Yes, that's what the Gnulib utimecmp module does: the idea is that after every stat-like operation you look at the file's time stamps to infer more information about the containing file

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

2014-08-26 Thread Paul Smith
On Tue, 2014-08-26 at 18:04 +0300, Eli Zaretskii wrote: > > (I don't know why Windows doesn't, because NTFS does support > > millisecond resolution timestamps I believe) > > Because no one wrote the code, of course. Ah, the oldest reason in free software :-). > The main problem is that this requ

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

2014-08-26 Thread Eli Zaretskii
> From: Paul Smith > Date: Tue, 26 Aug 2014 10:52:32 -0400 > Cc: Autoconf , Eric Blake , > bug-make > > Of course the ability to track filesystems could be added without too > much effort. It's trivial to determine the filesystem in POSIX via the > device ID available from stat(), of cour

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

2014-08-26 Thread Paul Smith
On Sat, 2014-08-23 at 18:33 -0700, Paul Eggert wrote: > Paul Smith wrote: > > > It needs to be considered carefully. > > How about having GNU 'make' do what GNU 'cp -u' does? > > The idea is to infer filesystem timestamp resolution by looking at every > file timestamp that crosses your desk. W

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

2014-08-23 Thread Paul Eggert
Paul Smith wrote: It needs to be considered carefully. How about having GNU 'make' do what GNU 'cp -u' does? The idea is to infer filesystem timestamp resolution by looking at every file timestamp that crosses your desk. When you see a file timestamp whose tv_nsec is nonzero modulo 100

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

2014-08-23 Thread David Boyce
On Sat, Aug 23, 2014 at 6:25 PM, Paul Smith wrote: > I pretty much agree with everything Paul says in this thread. And I tend to agree with David right down the line :-) But I guess two Pauls beat a David. ___ Bug-make mailing list Bug-make@gnu.org htt

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

2014-08-23 Thread Paul Smith
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

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

2014-08-21 Thread Paul Eggert
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.

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

2014-08-21 Thread David Boyce
On Thu, Aug 21, 2014 at 12:27 PM, Ray Donnelly wrote: > On Thu, Aug 21, 2014 at 8:03 PM, David Boyce wrote: >> The obvious compromise would be to change the behavior only in the >> presence of the ".POSIX:" special target. > > Sounds pragmatic; the repeatable builds people would probably like a >

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

2014-08-21 Thread Ray Donnelly
On Thu, Aug 21, 2014 at 8:03 PM, David Boyce wrote: > The obvious compromise would be to change the behavior only in the > presence of the ".POSIX:" special target. Sounds pragmatic; the repeatable builds people would probably like a solution that doesn't require changing Makefiles though, either

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

2014-08-21 Thread David Boyce
The obvious compromise would be to change the behavior only in the presence of the ".POSIX:" special target. On Thu, Aug 21, 2014 at 9:13 AM, Paul Eggert wrote: > Eric Blake wrote: >> >> You may want to check out http://austingroupbugs.net/view.php?id=857 and >> add comments and/or change GNU mak

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

2014-08-21 Thread Paul Eggert
Ray Donnelly wrote: There was a bug in libfaketime so that the nanosecond field wasn't cleared That sounds like it's a different issue. If a program botches the nanosecond component of timestamps, it shouldn't matter whether 'make' uses the traditional/GNU or the HP-UX approach; either way,

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

2014-08-21 Thread Bob Friesenhahn
On Thu, 21 Aug 2014, Eric Blake wrote: The POSIX recommendation was therefore that GNU should change its behavior to act like HP-UX, and consider identical timestamps as out-of-date, because the standard will be fixed to allow HP-UX behavior. A change like this may result in some builds which

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

2014-08-21 Thread Paul Eggert
Eric Blake wrote: You may want to check out http://austingroupbugs.net/view.php?id=857 and add comments and/or change GNU make behavior accordingly. Let's leave GNU 'make' alone. Its behavior is better for rules like this: copy: original cp -p original copy I've added a comment to th

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

2014-08-21 Thread Ray Donnelly
On Thu, Aug 21, 2014 at 4:57 PM, Ray Donnelly wrote: > On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake wrote: >> Make folks: >> You may want to check out http://austingroupbugs.net/view.php?id=857 and >> add comments and/or change GNU make behavior accordingly. There, the >> argument is made that HP

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

2014-08-21 Thread Ray Donnelly
On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake wrote: > Make folks: > You may want to check out http://austingroupbugs.net/view.php?id=857 and > add comments and/or change GNU make behavior accordingly. There, the > argument is made that HP-UX make behavior is nicer than GNU's current > behavior whe

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

2014-08-21 Thread Eric Blake
Make folks: You may want to check out http://austingroupbugs.net/view.php?id=857 and add comments and/or change GNU make behavior accordingly. There, the argument is made that HP-UX make behavior is nicer than GNU's current behavior when two files have identical timestamps: HP-UX considers the fil