Re: Automake vs. autoheader: config.h.in

[Tom Tromey]

>>>>> "Paul" == Paul D Smith <address@hidden> writes:

Paul> So, autoreconf basically proceeds in this order: gettextize,
Paul> aclocal, automake, autoconf, autoheader.

Paul> This means that when automake is run as the third step, it
Paul> complains about a missing config.h.in (which isn't so bad), and
Paul> it doesn't add config.h.in to the list of common DISTFILES
Paul> (which _is_ so bad).

Paul> So, my question is is this a problem with autoreconf in that
Paul> autoheader should be run earlier?

Yes.  Automake wants to be run last.  Sometimes it examines the source
tree to make decisions about what to put in Makefile.in.  (A bit lame,
but historical.  I'm sure the sharp eyed will read this, perhaps
correctly, as eliminating my anti-globbing argument :-)

Paul> Or is it a fundamental circularity in the toolchain, and we just
Paul> need to run one or the other twice (probably run autoheader
Paul> before automake, then run it again after autoconf to pick up any
Paul> changes autoconf made, for example)?

I don't think autoconf and autoheader have a required ordering.

Tom