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: Stepan Kasal
Subject: Re: calling autoreconf and minimizing rebuilds
Date: Fri, 8 Sep 2006 16:11:22 +0200
User-agent: Mutt/1.4.2.1i

Hello,

On Fri, Sep 08, 2006 at 07:16:06AM +0200, Ralf Wildenhues wrote:
> [...], with Stepan's proposed additional patch
> http://lists.gnu.org/archive/html/autoconf-patches/2006-09/msg00023.html
> I can't get the test to fail reliably any more: it only fails about half
> the time, even if I throw most preselections out of the Automake part in
> autom4te.cfg.
> 
> So there is still something going on that we (at least I) don't
> understand right.  I haven't applied the patch yet.

my guess is that it all happens too fast; autoreconf calls
aclocal
autoconf
autoheader
automake -a

At the end of its work, autoconf writes configure.
autoheader is quick: the cached traces of configure.ac do not contain
AC_CONFIG_HEADER.
Then automake starts its work by caling autoconf, which calls
autom4te. Because of the aditional traces, m4 is called again, and
the files output.1 and traces.1 are refreshed.

If all of the above takes place within the same second, and if the
file system does not support sub-second timestamps, then configure
has the same timestamp as output.1 and traces.1.
(And yes, it is quite possible that the patch quoted above makes this
procedure faster, increasing  the probability that it all falls to
the same second.)

Back to the test: thank you very much that you wrote it, Ralf!

Actually, I did not imagine that the problem will be reproduced by a
call to autoreconf, I imagined the individual tools would be called.
(When I was analysing the problem, I did not use autoreconf either.)

More comments:
> +# If [...] the user has a local config, skip:
...
> +test -f $HOME/.autom4te.cfg && exit 77

I do not understand why this is necessary, but it is not a big deal.

For the tail of the script, I would use something like:

$ACLOCAL
$AUTOCONF
: >stamp
$sleep
$AUTOMAKE
test -z "`find configure -newer stamp`"

> I've made the test a bit more cautious, see below; I don't think
> bug-automake should get bug reports because users don't use
> Autoconf-2.60b or newer for their tests (but OTOH I don't think Automake
> should bump its global Autoconf requirements just for this caching bug
> either).

I agree with that but I think I see a bug in your implementation:

> +if $AUTORECONF; then :; else
> +  if test $? -eq 63 || test ! -d autom4te.cache; then
> +    exit 77
> +  fi
> +fi

What if autoconf and autoreconf succeed but caching is switched off?
The test for -d autom4te.cache is never reached and the script will
fail later.

I would suggest this (based on my above code):

$ACLOCAL
if $AUTOCONF; then
  test -d autom4te.cache || exit 77
else
  status=$?
  test $status != 63 || status=77
  exit $status
fi
: >stamp
$sleep
$AUTOMAKE
test -z "`find configure -newer stamp`"

Do these comments sound reasonable?

Stepan




reply via email to

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