[Gc]: Dependency tracking for configuration macros
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
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
@@ -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
-libtoolize --automake --force
+libtoolize --automake --force
echo "Ready to run './configure'."
More information about the Gc