[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
    

Attachment: pgpO9FA870sor.pgp
Description: PGP signature


Reply to: