bug#8365: 3 of 657 tests failed

[Ralf Wildenhues]

* 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/

>      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.

Cheers,
Ralf