Thanks for the detailed feedback, Peter. Jim, this is <http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3638/focus=3747>, and I'm a bit out of ideas; see at the very end.
* Peter Breitenlohner wrote on Fri, Dec 04, 2009 at 01:04:09PM CET: > On Wed, 2 Dec 2009, Ralf Wildenhues wrote: > > >>--- a/tests/aclocal9.test > >>+++ b/tests/aclocal9.test > >>@@ -42,6 +42,8 @@ $AUTOCONF > >> grep macro11 foo > >> grep macro21 foo > >> > >>+sleep 1 > >>+ > >> $ACLOCAL -I m4_2 -I m4_1 > >> $AUTOCONF > >> ./configure > > > >I don't yet understand why this should be necessary. > almost certainly this has to do with the rounding/truncation of sub-second > timestamps, possibly handled in a different way by Autotools and GNU Make > 3.81. Well, this test never calls 'make', so that shouldn't be involved. However, you're probably right in that this is about some tool using subsecond time stamps and another not doing so. So let's find out what does what: One involved tool is perl: perl -e 'use File::stat; print (stat("README")->mtime . "\n");' Another is the shell/test, and ls: Create two files with same-second but different sub-second time stamps (try until this succeeds): echo stamp > file1 echo stamp > file2 ls -l --full-time file? then test 'test' and 'ls': if test file2 -nt file1; then echo "shell test uses sub-second"; fi if /usr/bin/test file2 -nt file1; then echo "/usr/bin/test uses sub-second"; fi set X `ls -Lt file1 file2` if test $3 = file1; then echo "ls uses sub-second"; fi For completeness let's also test 'make': echo 'file1: file2; echo "make uses sub-second"' > Makefile make and whether 'touch -r' can generate sub-second stamps: : > foo touch -r foo bar ls -l --full-time foo bar > To fit into my infrastructure I did: > cd test > make TESTS='aclocal9.test' check > but that should be equivalent. Yes, that's fine. > The third attempt failed; the files you asked for are attached, together > with the output from "ls -lrt --fu aclocal9.dir". The output proves that aclocal did update aclocal.m4: > + tail aclocal.m4 [...] > m4_include([m4_1/somedefs.m4]) > + autoconf [...] > + tail aclocal.m4 [...] > m4_include([m4_1/somedefs.m4]) > m4_include([m4_2/somedefs.m4]) > + autoconf > Output from "ls -lrt --fu aclocal9.dir": > > total 192 [...] > drwxr-xr-x 2 peb THEORY 8 2009-12-04 11:57:00.509038757 +0100 m4_2 > drwxr-xr-x 2 peb THEORY 8 2009-12-04 11:57:00.509038757 +0100 m4_1 > -rw-r--r-- 1 peb THEORY 86 2009-12-04 11:57:00.509038757 +0100 configure.in > -rw-r--r-- 1 peb THEORY 15948 2009-12-04 11:57:00.882197557 +0100 > aclocal-log-1 > -rwxr-xr-x 1 peb THEORY 66329 2009-12-04 11:57:01.118709661 +0100 configure > drwxr-xr-x 2 peb THEORY 4096 2009-12-04 11:57:01.505099509 +0100 > autom4te.cache > -rw-r--r-- 1 peb THEORY 15993 2009-12-04 11:57:01.525161570 +0100 > aclocal-log-2 > -rw-r--r-- 1 peb THEORY 22331 2009-12-04 11:57:01.529182308 +0100 aclocal.m4 > -rw-r--r-- 1 peb THEORY 16 2009-12-04 11:57:01.739640973 +0100 foo > -rw-r--r-- 1 peb THEORY 4931 2009-12-04 11:57:01.759754356 +0100 config.log This shows that the second "autoconf" did not update configure. Can you post, for this same build, also ls -lrt --fu autom4te.cache please? Thanks. 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 Ugh. If Cygwin weren't so slow, it would fall prey to this issue, too. 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? Thanks, Ralf