autoconf-patches
[Top][All Lists]
Advanced

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

Re: sub-second time stamp issues


From: Eric Blake
Subject: Re: sub-second time stamp issues
Date: Mon, 11 Jan 2010 05:55:47 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

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
> address@hidden 1} in rules depending on targets that are created with
> address@hidden -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             address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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