On Wednesday 30 March 2011, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Wed, Mar 30, 2011 at 06:10:23PM CEST: > > Now, why is configure not re-run? Here is my (longish) tentative > > explanation, > > step by step. In what follows, I'll use the abbraviation `TS(f)' to indicate > > the timestamp (i.e. last modification time) of the file `f'. > > > > 01. configure is run for the first time; it concludes its execution > > creating > > the `config.status' script and the `Makefile' and `sub/Makefile' files, > > which are all assured to be created older than configure (see code in > > s/older/newer/ > Yes, that's what I meant. Sorry for the blunder.
> > sanity.m4:AM_SANITY_CHECK). > > > > 02. Since the creations of `config.status', `Makefile' and `sub/Makefile' > > take place very near, it's quite likely they'll have the same > > timestamp; > > let's assume this is indeed the case: > > [E1] TS(config.status) = TS(Makefile) = TS(sub/Makefile) > > > > 03. make is run for the first time; all is up-to-date at this point, so > > that > > nothing gets rebuilt -- basically a no-op; > > > > 04. the test script modifies the aclocal dependencies `m4/somedef.m4' and > > `acinclude.m4', *without sleeping* before doing this modification (this > > lack of a `sleep' is very important; see point 7 below). > > > > 05. make is called again right away *from the `sub' subdirectory*; it sees > > that `m4/somedef.m4' and `acinclude.m4' are newer than > > `sub/Makefile.in' > > (which depends on them), and it knows that `sub/Makefile' depends on > > `sub/Makefile.in'. So a recursive make call is issued, to run the > > special target `am--refresh' *in the top-level directory*, in order to > > bring `sub/Makefile.in' up-to-date. > > > > 06. This "recursive" make, running in the top-level directory, similarly > > sees that `m4/somedef.m4' and `acinclude.m4' are newer than > > `Makefile.in' > > (which depends on them), and that `Makefile' depends on `Makefile.in'. > > It also sees that `Makefile' depends on `config.status', which in turn > > depends on `configure', which in turn depends on `aclocal.m4'. > > > > 07. At this point, make issues calls to aclocal, autoconf and automake in > > order to bring up-to-date the various files that `Makefile' depends on. > > After the autotools have run, we have: > > [E3] for each x in { Makefile.in, sub/Makefile.in, configure, > > aclocal.m4 } > > for each y in { config.status, sub/Makefile, Makefile, > > m4/somedef.m4, > > acinclude.m4 } > > it is TS(x) >= TS(y) > > Point 07 doesn't make sense to me. Well, it doesn't explain the actual > issue, the problem why a configure rerun is not triggered by am--refresh. > I suspect the actual issue is an autom4te caching one; because it looks > like either aclocal or autoconf (or both) concluded that their output > files wouldn't need updating for some reason. > > We need to find out this reason. > > Because if configure had been updated, then 'make' would have run > 'config.status --recheck' which would have restored the world order > that config.status is newer than configure. > > So sorry, but we're still stuck in analysis. > I think I've now managed to definitively confirm my explanation, this time with the backup of real data (thanks to Sam for providing that!) and *reproducible* testsuite exposure. Please see the newer and more clear analysis of subdir5.test failure in this same thread. Sorry for the noise, Stefano