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
