[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: POSIX ruling on up-to-date vs. identical timestamps
From: |
Ray Donnelly |
Subject: |
Re: POSIX ruling on up-to-date vs. identical timestamps |
Date: |
Thu, 21 Aug 2014 16:57:44 +0100 |
On Thu, Aug 21, 2014 at 4:32 PM, Eric Blake <address@hidden> 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 when two files have identical timestamps: HP-UX considers the
> file as out-of-date, while GNU make considers it up-to-date. A strict
> reading of POSIX can argue that GNU's behavior was required, but this
> reading has been called into question.
>
> GNU's behavior is an optimization that avoids needless churn on file
> systems with course timestamps (well, FAT still exists, but these days,
> MOST file systems have sub-second resolution, so it is harder to get
> files with identical timestamps without actually touch'ing them that
> way) - but it risks leaving a tree in an incomplete state. HP-UX
> behavior guarantees the rules are run, even if they were not strictly
> necessary, but has the nice property that the tree is never left in an
> incomplete state due to unfortunate timing on a file system with course
> timestamps.
>
> 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.
>
> Autoconf folks:
> The section of the autoconf manual that discusses this should probably
> be modernized, particularly if changes to POSIX and/or GNU make result
> from this discussion.
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Timestamps-and-Make
>
Some projects that want to have deterministic builds by using the
gitian builder [1] use libfaketime to set the timestamps to a known
constant, and gnu make trips up on this, occasionally causing broken
builds and othertimes autoconf declares suck a build system "insane".
There was a bug in libfaketime so that the nanosecond field wasn't
cleared and this allowed you to avoid both these bugs if the planets
were aligned correctly (which has since been fixed). I agree that
these issues should be fixed in make and autoconf.
[1] https://gitian.org/
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make
>
- POSIX ruling on up-to-date vs. identical timestamps, Eric Blake, 2014/08/21
- Re: POSIX ruling on up-to-date vs. identical timestamps,
Ray Donnelly <=
- Re: POSIX ruling on up-to-date vs. identical timestamps, Paul Eggert, 2014/08/21
- Re: POSIX ruling on up-to-date vs. identical timestamps, David Boyce, 2014/08/21
- Re: POSIX ruling on up-to-date vs. identical timestamps, Paul Eggert, 2014/08/21
- Re: POSIX ruling on up-to-date vs. identical timestamps, Paul Smith, 2014/08/23
- Re: POSIX ruling on up-to-date vs. identical timestamps, David Boyce, 2014/08/23
- Re: POSIX ruling on up-to-date vs. identical timestamps, Paul Eggert, 2014/08/23