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
