autoconf
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: POSIX ruling on up-to-date vs. identical timestamps
Date: Thu, 21 Aug 2014 09:32:42 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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