Hi,

I've just built automake-1.12.2 and had the aclocal7.sh test fail. After
a bit of investigation, it's because the test:

- creates a .m4 file;
- calls aclocal;
- calls automake;
- sleeps for a bit;
- calls aclocal again;
- calls automake again;
- checks that those two calls didn't actually write any files.
  [then goes on to test some other stuff that works fine]

The problem is that aclocal decides whether to rewrite its output file
by checking that all of the input files it's read are older than the
existing output file. If aclocal takes less than a second to run in the
sequence above, it's possible for its output file to have the same
timestamp as the .m4 file -- and then the second call to aclocal will
decide the output file needs rewriting, and the test fails.

The attached patch adds a $sleep after creating the .m4 file, so it'll
definitely be older than the first aclocal's output.

Thanks,

-- 
Adam Sampson <a...@offog.org>                         <http://offog.org/>
Fix a race condition that causes aclocal7 to fail on fast machines (see the
comment below).

diff -x config.log -x config.status -ru tmp/automake-1.12.2/t/aclocal7.sh 
work/automake-1.12.2/t/aclocal7.sh
--- tmp/automake-1.12.2/t/aclocal7.sh   2012-07-08 11:48:25.000000000 +0100
+++ work/automake-1.12.2/t/aclocal7.sh  2012-07-10 11:58:50.325999591 +0100
@@ -45,6 +45,11 @@
   $AUTOMAKE --no-force
 }
 
+# aclocal will rewrite aclocal.m4 unless the input files are all older than the
+# existing aclocal.m4 -- sleep to ensure somedefs.m4 has an older timestamp
+# than the aclocal.m4 that the next aclocal call will generate.
+$sleep
+
 $ACLOCAL -I m4
 AUTOMAKE_after_aclocal
 

Reply via email to