File: autoconf.info, Node: Timestamps and Make, Prev: Single Suffix Rules, Up: Portable Make 12.20 Timestamp Resolution and Make =================================== Traditionally, file timestamps had 1-second resolution, and ‘make’ used those timestamps to determine whether one file was newer than the other. However, many modern file systems have timestamps with 1-nanosecond resolution. Some ‘make’ implementations look at the entire timestamp; others ignore the fractional part, which can lead to incorrect results. Normally this is not a problem, but in some extreme cases you may need to use tricks like ‘sleep 1’ to work around timestamp truncation bugs. Traditionally, commands like ‘cp -p’ and ‘touch -r’ did not copy file timestamps to their full resolutions (*note Limitations of Usual Tools: touch.). Hence you should be wary of rules like this: dest: src cp -p src dest as ‘dest’ often appears to be older than ‘src’ after the timestamp is truncated, and this can cause ‘make’ to do needless rework the next time it is invoked. To work around this problem, you can use a timestamp file, e.g.: dest-stamp: src cp -p src dest echo >dest-stamp Apart from timestamp resolution, there are also differences in handling equal timestamps. Although POSIX suggests that ‘make’ update a target with the same timestamp as its newest prerequisite, only HP-UX ‘make’ is known to do so; GNU and other ‘make’ implementations do not update, a behavior that POSIX also allows. The HP-UX behavior can cause spurious rebuilds and this in turn can cause ‘make’ to fail if it tries to rebuild generated files in a possibly read-only source tree with tools not present on the build machine. Conversely, if a source file is updated immediately after running ‘make’ in a file system with low-resolution timestamps, the GNU behavior can cause a later ‘make’ to neglect rebuilds and quietly generate incorrect results. To avoid both these problems, use GNU ‘make’ on a platform with high-resolution timestamps.
