bug#8365: 3 of 657 tests failed

[Stefano Lattarini]

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