[Top][All Lists]

[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: Wed, 6 Sep 2006 23:05:38 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello David,

* David Byron wrote on Wed, Sep 06, 2006 at 08:57:21PM CEST:
> I repeated the test, running make as
> $ make -d -p -r >make.out 2>&1
> and see this:
>     Prerequisite `../configure' is newer than target `config.status'.
>    Must remake target `config.status'.
> /bin/sh ./config.status --recheck
> automake 1.9.6, autoconf 2.60.
> Any ideas?

autoconf and automake (and aclocal) all use autom4te behind the scenes,
which itself does some caching (below autom4te.cache) and checks
timestamps of file configure depends upon.  You could use things like
  AUTOCONF='autoconf --verbose' autoreconf -vi

to find out why it thinks it needs to update configure the first time.

A bit of testing makes me think the reason is something like this:
autoreconf calls the tools roughly in this order (unnecessary parts

When we issue automake for the first time, it needs to create a new
traces.x file, and thus also creates a new output.x file.  That file
is identical to traces.x-1 but it is _newer_.  So next time autoconf
is run, it compares the mtime of configure against that of traces.x,
instead of traces.x-1.

If I run them in the order

then configure is not older than any file below autom4te.cache.  Thus,
if I repeat the commands, configure is not updated.

I'm not sure what the underlying root of this bug is, whether autom4te
could compare against the oldest output.y file which compares equal to
all newer output.x files, nor whether we can just switch execution
order of automake and autoconf.  I haven't tried autoheader in my test.

Cheers, and thanks for the report,

reply via email to

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