GNU bug report logs -
#8365
3 of 657 tests failed
Previous Next
Reported by: sds <at> gnu.org
Date: Mon, 28 Mar 2011 14:49:03 UTC
Severity: normal
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #35 received at 8365 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 14 years and 106 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.