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

[Ralf Wildenhues]

Hello Peter,

thanks for the report and patch.

* Peter Breitenlohner wrote on Tue, Nov 24, 2009 at 10:44:31AM CET:
> as I mentioned a few weeks ago, I get a few FAILs when runnig 'make check'
> on the current Automake-git.  Looking into the three tests I concluded that
> it must be a timing problem.  Running ten times just these three tests I
> got:
> 
> aclocal9: 6 FAIL + 4 PASS
> acloca10: 10 FAIL
> nodef: 8 FAIL + 2 PASS
> 
> after applying the attached patch I got 10 PASSes for each test.
> 
> The patch introduces a delay between successive invocations of aclocal.
> Probably using 'aclocal -f' would have the same effect, but a delay --
> undesirable as it might be -- seems to be closer to a typical use case.
> 
> BTW: There may be additional test suffering from the same problem.

We'll deal with each such failure one by one.  I would like to find and
understand any bugs that might be lurking here, and not paper over them.

> --- 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.  The sequence
here looks like this, where aclocal.m4 contents depend upon aclocal
argument order:

  $ACLOCAL -I m4_1 -I m4_2
  $AUTOCONF
  ./configure
  [...]

  $ACLOCAL -I m4_2 -I m4_1
  $AUTOCONF

The sanity check in configure ensures that files generated by configure
are (strictly) newer than configure.  configure itself is at least as
new as the first version of aclocal.m4.  The second aclocal must
generate a new output file, because its contents have changed.  That
aclocal.m4 file is then strictly newer than configure, thus the second
autoconf must update configure.

So, off to find out where my hypothesis goes wrong.
Can you apply this diff, run the test as
  cd tests
  $srcdir/aclocal9.test

repeatedly until it fails for you, then send the two aclocal-log-?
files as well as the test output?  Thanks.

Which Autoconf version do you use?

--- a/tests/aclocal9.test
+++ b/tests/aclocal9.test
@@ -36,13 +36,15 @@ cat >m4_2/somedefs.m4 <<EOF
 AC_DEFUN([MACRO1], [echo macro12 > foo])
 EOF
 
-$ACLOCAL -I m4_1 -I m4_2
+$ACLOCAL -I m4_1 -I m4_2 --verbose 2> aclocal-log-1
+tail aclocal.m4
 $AUTOCONF
 ./configure
 grep macro11 foo
 grep macro21 foo
 
-$ACLOCAL -I m4_2 -I m4_1
+$ACLOCAL -I m4_2 -I m4_1 --verbose 2> aclocal-log-2
+tail aclocal.m4
 $AUTOCONF
 ./configure
 grep macro12 foo


> --- a/tests/nodef.test
> +++ b/tests/nodef.test
> @@ -45,6 +45,8 @@ grep 'DEFS.*-DVERSION=\\"UnIqUe' output
>  
>  # Then, check that PACKAGE and VERSION are not output if requested.
>  
> +sleep 1
> +
>  cat > configure.in << 'END'
>  AC_INIT
>  AM_INIT_AUTOMAKE([UnIqUe_PaCkAgE], [UnIqUe_VeRsIoN], [no])

I don't understand why this sleep should be necessary.  When the first
configure is run, either it sleeps, or configure is older than the
current time, which means that configure.in is also older than the
current time.  That in turn means the update of configure.in must result
in a newer timestamp.  So the sleep should not be necessary here either.

I haven't looked in detail at acloca10.test, but assume that a similar
reasoning as for aclocal9.test should hold.

Thanks,
Ralf