automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef


From: Jim Meyering
Subject: Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef
Date: Fri, 04 Dec 2009 23:00:33 +0100

Ralf Wildenhues wrote:
...
> My hypothesis as to what's going on:
>
> The first configure run causes no sanity sleep second because ls -Lt
> makes use of subsecond stamps.  The second aclocal produces an
> aclocal.m4 file still within the same second as the first configure was
> produced.  The second autoconf invokes autom4te, which is perl, which
> only uses one-second granularity(?), thus does not see that aclocal.m4
> is newer than configure, thus uses the cached output.  Boing.
>
> Let's see if your data confirms this.  I just tried out my Cygwin
> install:
>
> tool              sub-second?
> -----------------------------
> file system       yes
> perl              no
> shell test        no
> /usr/bin/test     yes
> ls                yes
> make              yes
> touch -r          yes

Hi Ralf,

I haven't looked into the portability constraints yet, but
the stat replacement from Perl's Time::HiRes module might help:

    $ touch k; rm k;
    $ perl -le 'use Time::HiRes qw(stat); $t=(stat ".")[9]; print $t'
    1259963881.12454
    $ touch k; rm k;
    $ perl -le 'use Time::HiRes qw(stat); $t=(stat ".")[9]; print $t'
    1259963881.22454


> I think we either need to reintroduce the 'sleep 1' in the build sanity
> check, or some other way to ensure that a file newly created by
> configure has a time stamp with a strictly larger integer part than the
> time stamp of the configure script.  Any ideas of what the most portable
> way to achieve this could be?
>
> We may be able to get by with something like spawning off a
>   ( sleep 1 ) &
>
> early in the configure script, and ensuring that it has completed before
> we get to config.status creation.  I'm a bit afraid of introducing
> 'kill' into configure scripts, however.  Any less dangerous ideas?




reply via email to

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