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. When you
From: Paul Smith psm...@gnu.org
Date: Tue, 26 Aug 2014 10:52:32 -0400
Cc: Autoconf autoc...@gnu.org, Eric Blake ebl...@redhat.com,
bug-make bug-make@gnu.org
Of course the ability to track filesystems could be added without too
much effort. It's trivial to determine the filesystem in
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 requires
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
From: Paul Smith psm...@gnu.org
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)?
Date: Tue, 26 Aug 2014 08:25:38 -0700
From: Paul Eggert egg...@cs.ucla.edu
Cc: Autoconf autoc...@gnu.org, Eric Blake ebl...@redhat.com,
bug-make bug-make@gnu.org
As far as Windows goes, NTFS file systems have 100 ns resolution, and
FAT file systems are the joker as they have a
Date: Tue, 26 Aug 2014 18:30:12 +0100
From: Keith Marshall keithmarsh...@users.sourceforge.net
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
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
On 26/08/14 18:22, Eli Zaretskii wrote:
Date: Tue, 26 Aug 2014 08:25:38 -0700
From: Paul Eggert egg...@cs.ucla.edu
Cc: Autoconf autoc...@gnu.org, Eric Blake ebl...@redhat.com,
bug-make bug-make@gnu.org
As far as Windows goes, NTFS file systems have 100 ns resolution, and
FAT file
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
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
On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake ebl...@redhat.com 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
On Thu, Aug 21, 2014 at 4:57 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake ebl...@redhat.com 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.
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
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
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,
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 egg...@cs.ucla.edu wrote:
Eric Blake wrote:
You may want to check out http://austingroupbugs.net/view.php?id=857 and
add comments and/or
On Thu, Aug 21, 2014 at 12:27 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
On Thu, Aug 21, 2014 at 8:03 PM, David Boyce david.s.bo...@gmail.com wrote:
The obvious compromise would be to change the behavior only in the
presence of the .POSIX: special target.
Sounds pragmatic; the repeatable
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.
19 matches
Mail list logo
