On Wednesday 30 March 2011, Ralf Wildenhues wrote: > Hi Stefano, > > * Stefano Lattarini wrote on Wed, Mar 30, 2011 at 06:47:20PM CEST: > > --- a/tests/aclocal6.test > > +++ b/tests/aclocal6.test > > > @@ -57,6 +57,8 @@ cd build > > ../configure > > $MAKE > > > > +# Modified configure dependencies must be newer than config.status. > > +$sleep > > # Update an aclocal.m4 dependency, then make sure all Makefiles > > # are updated, even from a sub-directory. > > echo 'AC_DEFUN([SOME_DEFS], [MORE_DEFS])' > ../m4/somedefs.m4 > > > --- a/tests/subdir5.test > > +++ b/tests/subdir5.test > > > @@ -67,6 +67,8 @@ $MAKE > > # does it in the other way: it updates confiles.m4 (which is m4_included > > # by configure.in there) after Makefile.am. > > > > +# Modified configure dependencies must be newer than config.status. > > +$sleep > > This hunk makes perfect sense to me, and is fine for maint, > but the other two do not make sense to me yet: > configure ensures that config.status is newer than itself, > Yes, I have taken that into account.
> thus configure must be older than any .m4 files that are > edited afterwards even without $sleep. > Yes; problem is, config.status won't (necessarily) be. And this is what's causing the failure here. > I've read the longish explanation of yours superficially; > if you think it addresses my concern please say so and I will > scrutinize it. > I think it does; maybe reformulating it for subdir5.test would make it clearer (ans surely shorter); I might do that if you are interested (not right now, but soonish enough). > > sed <configure.in >configure.tmp -e '/^AC_OUTPUT$/i\ > > AC_CONFIG_FILES([maude/Makefile])\ > > m4_include([confile.m4])\ > > @@ -94,6 +96,8 @@ test -f maude/Makefile > > # Then we add a new directory by modifying a file included (through > > # `m4_include') by configure.in. > > mkdir maude2 > > +# Modified configure dependencies must be newer than config.status. > > +$sleep > > cat >> confile.m4 << 'END' > > AC_CONFIG_FILES([maude2/Makefile]) > > AC_SUBST([GREPME]) > > Thanks for looking into this, > Ralf > Thanks, Stefano