[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: to autoconf or not (was Re: Multi-OS Makefiles)
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: to autoconf or not (was Re: Multi-OS Makefiles)
- From: Marc Espie <espie_(_at_)_nerim_(_dot_)_net>
- Date: Sun, 8 Aug 2004 12:11:51 +0200
- Mail-followup-to: misc_(_at_)_openbsd_(_dot_)_org
- Reply-to: espie_(_at_)_nerim_(_dot_)_net
It's a perspective issue.
If you run into issues that autoconf/automake/libtool get wrong, then
you have a hell of a time getting things to work right.
Plus, those auto-generated files are not always regenerated. A lot of
people distribute Makefile.in that were built with an older version of
automake, and they haven't rebuilt it, because it works with their
system and the Makefile.am didn't change. But the more recent automake
fixed bugs in other systems, and those people are hosed.
Those tools always assume a gnu environment as well. Makefiles generated
by automake/autoconf tend to work with gnu-make, and have reduced
functionality, or no functionality with bsd-make. In a gratuitous way,
in many cases. libtool assumes a very specific way to handle shared
libraries. and it's flawed in its design: it assumes it can get everything
it needs from the compiler with one compile. Even though gcc itself
doesn't, and has escape mechanisms to vary behavior based on options.
For instance, OpenBSD has architectures where the library path varies
depending on -fpic, and libtool still gets it wrong.
Also, some of the choices made in those tools are very dubious. Like
automake recursion handling, which allows it to have targets that do
stuff in the current directory, and recurse... personally, I wouldn't
allow that. The resulting makefile would be simpler, and you wouldn't
lose any real functionality. Or basing autoconf on m4, with all the
or libtool, which is probably the most fucked up design I've ever seen.
It's a complete nightmare finding one's way through a 3000+ lines
shell-script. Add to that the fact that half the checks are done at
libtool script creation time, half the checks at libtool runtime, where
they could all be done in one place. Complete wackiness.
Those tools are also a nightmare from a security point of view. My favorite
example is an update of libdvdread. ChangeLog entries:
- support for win32 (ten lines of code)
- regen with newer autoconf/automake
Result: 10000+ lines diff.
People creating ports often DON'T check that the diff is okay. There are
also cases where it's not really practical to, either because the people
behind the software didn't provide all the files, or because they're
using a mutant version of autoconf/automake/*.m4 macros... which is VERY
frequent, because at some points, the people in charge of autoconf and
automake had completely fucked up release policies, and so you were either
stuck with a non-working version, for your purposes, or you had to go
the experimental way (to wit: all the libtool experiments to `support'
Oh yes, another nightmare: getting stuff fixed upstream. When you find
a bug that amounts to a configure issue, you can't get it fixed directly
in the configure script, because it will be lost when autoconf gets
rerun. So, you have to fix configure.in, which is harder, or autoconf
itself, which often takes a lot of time...
I could go on, and on...