Re: calling autoreconf and minimizing rebuilds

[Ralf Wildenhues]

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
omitted):
  aclocal
  autoconf
  automake

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
  aclocal
  automake
  autoconf

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,
Ralf