Re: config.h as dependency

[Ralf Wildenhues]

Hello Jason,

* Jason Sewall wrote on Tue, Apr 21, 2009 at 05:22:40PM CEST:
> I have a project using autoconf + automake + autoheader, and clearly
> the results of my builds depends on what is in config.h. Thus, I would
> expect that when I run ./configure, everything in the build tree would
> be marked as out-of-date and everything would be rebuilt - that is, I
> would expect target to have @top_builddir@/config.h as an implicit
> dependency.

Well, automake implements side-effect dependency tracking, so yes,
everything should be rebuilt that depends on config.h.

> I understand that running make clean && ./configure solves this
> problem, but I was curious if there was a reasoning for this behavior.

"make clean" should not be necessary.

> Any thoughts? I've only been using autotools for a few months on just
> a few projects and I don't have an expert command of how they work.

Here's a few reasons why this may not have worked as intended:

- config.h wasn't even updated.  configure, more precisely
config.status, updates the header lazily, that is, doesn't touch it if
nothing changed.

- no suitable dependency tracking mode was found to work with your
compiler (and make version).  Look at the configure output similar to
  configure: checking dependency style of gcc ...

If the result is "none", then you can try rerunning configure with
  --enable-dependency-tracking

added, then also "slow" dependency tracking mechanisms will be
considered.  However, if you're using GCC and GNU make, then this should
definitely not be necessary, and there could be a bug somewhere (and
we'd like to know about it then).

There can be a couple more subtle issues but let's see your feedback on
this first.

Cheers,
Ralf