[Top][All Lists]

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

Re: config.h as dependency

From: Ralf Wildenhues
Subject: Re: config.h as dependency
Date: Wed, 22 Apr 2009 07:09:08 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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

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.


reply via email to

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