Re: Converting configure.in for use with new auto* tools - what a mess!
On Sat, Sep 27, 2003 at 01:54:36PM -0500, Branden Robinson wrote:
On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote:
I use the attached bootstrap script to build the autotools scripts. the
version of autotools are hardcoded in it, which is a Bad Thing (TM). Feel
free to steal anyway ;)
As far as I could tell, this message had no attachment (apart from the
message body and signature).
Ups
#!/bin/sh
##
## Some defs
##
PKG_NAME=w3c-libwww
# a list of all dirs containing possibly some macros
acmacrodirs=${HOME}/share/aclocal ${PWD}/tools/acmacro ${PWD}/m4
##
## End of conf part
##
for dir in $acmacrodirs ; do
if test -d $dir ; then
aclocalinclude=$aclocalinclude -I $dir;
fi
done
srcdir=`dirname $0`
test -z $srcdir srcdir=.
echo Autoregenerate package \`$PKG_NAME' in directory \`$srcdir';
(test -f $srcdir/configure.ac \
test -f $srcdir/Robot/src/RobotMain.c) || {
echo -n **Error**: Directory \`$srcdir\' does not look like the
echo top-level $PKG_NAME directory
exit 1
}
##
## Some tests (borrowed from Mt who borrowed it from
## macros/autogen.sh from achtung)
##
DIE=0
(autoconf --version) /dev/null /dev/null 21 || {
echo
echo **Error**: You must have \`autoconf' installed to compile $PKG_NAME.
echo Download the appropriate package for your distribution,
echo or get the source tarball at ftp://ftp.gnu.org/pub/gnu/;
DIE=1
}
(grep ^AM_PROG_LIBTOOL $srcdir/configure.ac /dev/null) {
(libtool --version) /dev/null /dev/null 21 || {
echo
echo **Error**: You must have \`libtool' installed to compile $PKG_NAME.
echo Get ftp://ftp.gnu.org/pub/gnu/libtool-1.4.tar.gz;
echo (or a newer version if it is available)
DIE=1
}
}
(automake-1.7 --version) /dev/null /dev/null 21 || {
echo
echo **Error**: You must have \`automake' 1.7 installed to compile
$PKG_NAME.
echo Get ftp://ftp.gnu.org/pub/gnu/automake-1.7.tar.gz;
echo (or a newer version if it is available)
DIE=1
NO_AUTOMAKE=yes
}
# if no automake, don't bother testing for aclocal
test -n $NO_AUTOMAKE || (aclocal --version) /dev/null /dev/null 21 || {
echo
echo **Error**: Missing \`aclocal'. The version of \`automake'
echo installed doesn't appear recent enough.
echo Get ftp://ftp.gnu.org/pub/gnu/automake-1.3.tar.gz;
echo (or a newer version if it is available)
DIE=1
}
if test $DIE -eq 1; then
exit 1
fi
## END of test part
##
## Action part
##
if test -z $*; then
echo **Warning**: I am going to run \`configure' with no arguments.
echo If you wish to pass any to it, please specify them on the
echo \`$0\' command line.
echo
fi
echo Generating configuration files for $PKG_NAME, please wait
echo;
case $CC in
xlc )
am_opt=--include-deps;;
esac
#for coin in `find $srcdir -name configure.ac -print `\
# `find $srcdir -name configure.in -print`
for coin in $srcdir/configure.ac
do
dr=`dirname $coin`
if test -f $dr/NO-AUTO-GEN; then
echo skipping $dr -- flagged as no auto-gen
else
echo
echo * Processing directory $dr
echo
if [ -e $dr/configure.in ] ; then
configfile=configure.in
else
configfile=configure.ac
fi
macrodirs=`sed -n -e 's,AM_ACLOCAL_INCLUDE(\(.*\)),\1,gp' $coin`
pwd=`pwd`
cd $dr
if grep ^AM_PROG_LIBTOOL $configfile /dev/null; then
if test -z $NO_LIBTOOLIZE ; then
echo Running libtoolize --force --copy in `pwd`...
libtoolize --force --copy
fi
fi
echo Running aclocal-1.7 $aclocalinclude...
aclocal-1.7 $aclocalinclude
if grep ^AM_CONFIG_HEADER $configfile /dev/null; then
echo Running autoheader in `pwd`...
autoheader
fi
echo Running automake-1.7 --gnu --add-missing $am_opt ...
automake-1.7 --gnu --add-missing $am_opt
# echo Running automake m4/Makefile ...
# automake m4/Makefile
echo Running autoconf...
autoconf
cd $pwd
fi
done
#conf_flags=--enable-maintainer-mode
if test x$NOCONFIGURE = x; then
echo
echo * Running $srcdir/configure $conf_flags $@ ...
echo
$srcdir/configure $conf_flags $@ || exit 1
else
echo Skipping configure process.
fi
echo Now type \`make\' to compile $PKG_NAME
pgp7O9BmjPUFR.pgp
Description: PGP signature
Re: Converting configure.in for use with new auto* tools - what a mess!
On Sat, 2003-09-27 at 11:23, Richard Atterer wrote: I've fixed a critical bug in w3c-libwww and now want to regenerate all the libtool/autoconf/automake files. Not trivial! With the same libtoolize/aclocal-1.4/autoheader2.13 under unstable, the latter gives FATAL ERROR: Autoconf version 2.50 or higher is required for this script. /usr/share/doc/libtool/README.Debian If you are developing software that still uses Autoconf 2.13 you will be unable to use this version of Libtool. It is strongly recommended that you update the software to use Autoconf 2.5x. If that is not possible you will need to install the deprecated GNU Libtool 1.4 release available in Debian as the 'libtool1.4' package. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Converting configure.in for use with new auto* tools - what a mess!
Hi, I've fixed a critical bug in w3c-libwww and now want to regenerate all the libtool/autoconf/automake files. Not trivial! The usual libtoolize/aclocal-1.4/autoheader2.13 etc works under testing, but I get build errors there, so I suspect I should try the latest versions in unstable. (The build error, incidentally, is that libtool wants to access files named foo/.libs/.libs/bar, when foo/.libs/bar would appear to be correct.) With the same libtoolize/aclocal-1.4/autoheader2.13 under unstable, the latter gives FATAL ERROR: Autoconf version 2.50 or higher is required for this script. Hrm :-/ So next I tried to convert the configure.in to work with newer versions of automake. I checked the quoting of strings containing commas, replaced all AM_ macro calls except for AM_INIT_AUTOMAKE/AM_CONFIG_HEADER, ran autoupdate and cleaned up the mess it made of the configure.in. Now I've got a configure.in for which autoheader2.50 *still* gives me the infamous undefined macro: _m4_divert_diversion error, even though I've followed the respective hints in the autoconf info pages. I've uploaded the file to http://atterer.net/debian/configure.in - could some autoconf-knowledgeable person please have a look at getting it to work with the w3c-libwww sources, or give me some hints what I need to fix? Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: Converting configure.in for use with new auto* tools - what a mess!
On Sat, Sep 27, 2003 at 12:23:54PM +0200, Richard Atterer wrote: Hi, I've fixed a critical bug in w3c-libwww and now want to regenerate all the libtool/autoconf/automake files. Not trivial! [...] I've uploaded the file to http://atterer.net/debian/configure.in - could some autoconf-knowledgeable person please have a look at getting it to work with the w3c-libwww sources, or give me some hints what I need to fix? I use the attached bootstrap script to build the autotools scripts. the version of autotools are hardcoded in it, which is a Bad Thing (TM). Feel free to steal anyway ;) First, remove acconfig.h from the archive. It triggers a warning in autoheader and is unneeded. (also remove the occurence of its name in Makefile.am) Do not erase it, but move it away. You'll need it afterward. Then, rename configure.in to configure.ac to make clear to the autotool that you are planing to use autoconf 2.50. And most of your problems comes from the fact that the acinclude.m4 (ie, the local definitions) contains macros of the same name than ones distributed by default in modern autoconf versions. Get rid of the definition of AC_C_VOLATILE and AC_HEADER_TIOCGWINSZ in acinclude.m4 Those macros are not used in the w3c-libwww source code (according to grep), and serve only to mess autoconf up. Then, there is a bazillon of warnings in autoheader about missing templates. It does complain about AC_DEFINE without third argument (giving the meaning of the define for comments in the www-config.h header). Get those comments from the acconfig.h file and put them as third argument where needed. If there is no second argument do: AC_DEFINE(HAVE_READDIR_R_3,,[Define to use the three-argument variant of readdir_r]) I would say it is safer to put the comment between square braces like that. Then automake-1.7 complains that way: Library/src/Makefile.am:53: CPPFLAGS' is a user variable, you should not override it; Library/src/Makefile.am:53: use AM_CPPFLAGS' instead. He is right. Defining CPPFLAGS from an Makefile.am is a Bad Thing (TM). Just rename the variable the way it tells you, it will take care of adding this to the right variable automatically. And the configure runs. I guess it means that your issues are solved. It was mainly the dupplicate definition of macros. autotools are always bitches about error messages. That's why I like them so much ;) If you need more help, please make available a tarball solving the bunch of warning trigered by autotools. HTH, Mt. -- The unavoidable price of reliability is simplicity. --Hoare pgpr0RyEbCvj9.pgp Description: PGP signature
Re: Converting configure.in for use with new auto* tools - what a mess!
On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote: I use the attached bootstrap script to build the autotools scripts. the version of autotools are hardcoded in it, which is a Bad Thing (TM). Feel free to steal anyway ;) As far as I could tell, this message had no attachment (apart from the message body and signature). -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks signature.asc Description: Digital signature
Re: Converting configure.in for use with new auto* tools - what a mess!
On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote: [lots of useful stuff] Many thanks indeed - that resolved all the problems! (But it took me a while to track down the additional old-style AC_DEFINEs in acinclude.m4, they also caused problems.) Unfortunately it turns out that the libtool in unstable still accesses foo/.libs/.libs/bar instead of foo/.libs/bar. But I've kludged around this by setting up a symlink .libs - . in the respective .libs directory, and that seems to work. Unless someone knows a better solution, I'll upload the package like that... Thanks again for your help! Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
