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?
