[Gc]: Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Fri Sep 25 12:33:23 PDT 2009

On 2009-09-25, Boehm, Hans wrote:
> We should regenerate and check in configure whenever configure.ac is updated.  I can do that later today, if it's difficult for you to do so.  I quickly tried to generate a configure, but didn't get a working version.
> One problem with the current tree appears to be a missing config.h.in in include/private.  Autogen.sh currently doesn't run autoheader.  Should it?  We probably also need to check in the resulting config.h.in, so that a plain configure will work again.  I tried that , but ended up with libtool version issues on my machine that will take a bit more time to deal with.

Yes, autogen.sh should run autoheader.  I don't think we really need
autogen.sh any longer since autoreconf is part of the Autoconf package,
but in case you want to keep it, I attach a patch which

* autogen.sh: Add autoheader and reorder the other tools to match that
of autoreconf.

Did you remove libtool.m4 before attempting to regenerate?  The file
cause plenty of warnings with recent autotools.  I think the file can be
safely removed from CVS because it's already included into configure for
the end user, and a developer who has the toolchain is likely also to
have a copy of libtool.m4 available.
-------------- next part --------------
diff --git a/autogen.sh b/autogen.sh
index afbfc55..3bbdf3a 100644
--- a/autogen.sh
+++ b/autogen.sh
@@ -5,7 +5,7 @@ set -e
 # These version are ok, pre-1.7 is not.  Post 1.7 may produce a lot of
 # warnings for unrelated projects, so prefer 1.7 for now.
-for v in 1.7 1.9 1.8; do
+for v in 1.10 1.9 1.8 1.7; do
     if type -p &>/dev/null automake-$v; then
@@ -21,10 +21,11 @@ if [ -z "$am_version" ]; then
 set -x
-libtoolize --automake --force
-automake$am_version -ac
+automake$am_version -ac
+libtoolize --automake --force
 set +x
 echo "Ready to run './configure'."

More information about the Gc mailing list