autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: calling autoreconf and minimizing rebuilds


From: Ralf Wildenhues
Subject: Re: calling autoreconf and minimizing rebuilds
Date: Mon, 11 Sep 2006 13:22:31 +0200
User-agent: Mutt/1.5.13 (2006-09-01)

Hello Stepan,

* Stepan Kasal wrote on Mon, Sep 11, 2006 at 12:26:34PM CEST:
> On Fri, Sep 08, 2006 at 09:50:48PM +0200, Ralf Wildenhues wrote:
> 
> > Closer.  We need to sleep before the first aclocal,
> 
> I do not understand why, but I'm afraid it has something to do with
> your explanation how aclocal and autm4te work.  I would be grateful
> for an explanation.

Sure.  If we don't sleep between the creation of configure.in (sic!)
and the invocation of aclocal, then aclocal.m4 may have the same time
stamp as configure.in.  The second time aclocal is invoked, it will
notice that aclocal.m4 is not younger than its inputs, namely it is not
younger than configure.in; so aclocal updates aclocal.m4.  The updated
timestamp will cause the next autoconf to update configure.

This behavior is due to how aclocal works: if input and output have the
same time stamp, it considers the output outdated, unlike how `make' and
`autom4te' behave.  (This was the most difficult bug to find, BTW.)

The reason I would like the test to call `aclocal' twice (once at the
beginning, and once when it should not update anything any more) is to
catch further possible bugs:  aclocal calls autom4te to trace `AC_DEFUN',
`AC_DEFUN_ONCE', `AU_DEFUN', `_AM_AUTOCONF_VERSION', and all macros
instantiated in installed configure inputs for which it saw a definition
in all the macro files it scanned.  The second invocation of aclocal
should make sure this set did not change.  If it did change, then
aclocal.m4 would be updated.

> > [...] and sleep before the
> > stamp (otherwise it's not guaranteed to be younger than configure),
> 
> Why does stamp has to be younger than configure?

Well, I would like the output of `ls -1t configure newer' to not depend
upon system-specific issues.  If `newer' and `configure' have different
time stamps, then there is no problem.  If they instead have the same
time stamp, the sort order depends upon the locale.  It's not easy to
imagine a locale where `newer' sorts before `configure', but it's easy
to avoid having to think about issues like this: by making sure they
always have different time stamps.

With this in mind, I have to differentiate between
- the `configure' that is generated by the first `autoconf' invocation
  (which, in case autom4te.cfg is good, is also the only generated one),
- and the `configure' that may be generated by the second `autoconf'
  invocation (in case autom4te.cfg specified too few macros, or the test
  should fail for some other reason).

I would like both failure and success to be deterministic.  Thus
sleeping before and after stamp file creation.

> Actually, I would use `test -r configure stamp' if it were portable.

I don't understand what you would like to achieve with this.

> >     * configure.ac: Preserve original values of `$AUTORECONF'
> >     and `$AUTOHEADER', to avoid the `missing' script.
> >     * tests/defs.in: Adjust.
> 
> You deleted am_AUTORECONF from the code, but not from the chlog
> entry.

Thanks for noting this; I'll fix the ChangeLog entry.

> I suggest to reinstert it to the code, to prevent an
> unpleasant surprise later.

Well, it is not needed in the testsuite at the moment, and it seems not
likely that it will be needed; and even if it would, bypassing `missing'
is merely an optimization, is does not harm execution.  To paraphrase in
your own words: Why have code that is never used?

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]