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

[Ralf Wildenhues]

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