According to Ralf Wildenhues on 1/10/2010 11:44 AM: >> That can hurt user-written makefile rules that use `cp -p' or `touch >> -r'. sanity.m4 can't help it really, because this can at best cause >> spurious rebuilds of all kinds of things, and at worst not cause >> updating of some targets. > > Proposed patch for the Autoconf manual. OK?
I'm okay with the patch, after you add a couple more points of clarification:
> Traditionally, file timestamps had 1-second resolution, and @samp{cp
> -p} copied the timestamps exactly. However, many modern file systems
> have timestamps with 1-nanosecond resolution. Unfortunately, @samp{cp
> --p} implementations truncate timestamps when copying files, so this
> -can result in the destination file appearing to be older than the
> +-p} implementations either truncate or round timestamps when copying files,
> +so this can result in the destination file appearing to be older than the
> source.
I'd like to see a mention that POSIX requires truncation, and that systems
that round are not (yet) POSIX-compliant.
> -
> +To avoid issues with rounded timestamps, you might need to introduce
> +...@code{sleep 1} in rules depending on targets that are created with
> +...@samp{cp -p} and @samp{touch -r}, to avoid @command{make} seeing them
> +as older than their prerequisites. Since this is error-prone, such
> +rules are best avoided.
With gnulib, we've empirically discovered that using sleep 0.02 (20
milliseconds, on platforms where sleep(1) and/or the shell has access to
subsecond sleep) is sufficient to avoid the bulk of the out-of-date
issues, rather than waiting the full second. But then we get into the
portability of how to specify sub-second sleeps. So I don't know if
adding any text along those lines is worthwhile, or just adds bulk to the
documentation with no benefit.
--
Don't work too hard, make some time for fun as well!
Eric Blake [email protected]
signature.asc
Description: OpenPGP digital signature
