[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
--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