[[resent from my subscribed email address after the mailing list rejected the original]]
Hi Enrico,
On 14 Nov 2010, at 02:24, Enrico Weigelt wrote:
> * ron minnich <rminn...@gmail.com> wrote:
>
>> If you're the kind of guy who can't resist changing things that don't
>> need changing, then you won't get it; perhaps you'd be better off
>> working on libtool. But Plan 9 is far from dead.
>
> Nobody with at least half-sane mind voluntarily works on or even
> with libtool ... it's basic concepts are fundamentally insane ;-o
People like to beat on GNU Libtool, and in some cases that criticism is
not undeserved... but in my experience, many critics of the tool come
from a perspective of building on a single architecture. If you have
never tried to build and link shared libraries from the same code-base
on 30 (or even 3) separate incompatible architectures, then you are
probably missing the point, and needn't read any further.
I'll be the first to admit that the complexity of the shell code inside
GNU Libtool is asymptotically approaching unmaintainable... and if I had
a lot more hacking time, I'd be spending more of it on untangling the
spaghetti. But that is an implementation issue, not a design problem.
That said, your comment strikes me as entirely unsubstantiated. Why do
you think the concepts themselves are insane? Setting aside the admitted
implementation shortcomings for the sake of argument; if you were
designing GNU Libtool from scratch, how would you do it differently?
AFAICT, without rewriting the entire GNU build system from the ground
up (and there is far too much momentum behind it to ever gain enough
traction to switch the GNU eco-system to an entirely new and different
build system anyway) the following precepts are immutable:
1. Unix variants (including POSIX layers of non-Unix architectures)
build shared libraries in vastly different ways, GNU Libtool
needs to handle all of them;
2. Similarly, there are many binary formats that handle run-time
loading of code in vastly different ways, all of which must be
handled too;
3. There's no use in fighting against GNU Autoconf and GNU Automake,
(and, believe me, I hate Perl as much as the next guy), so
integration with these is required - Libtool is not a build system
it just wants to provide a uniform interface to building and
loading dynamic shared objects;
4. GNU Libtool is a system bootstrap tool that is used to build some
of the very lowest level components of a Unix installation, so
it needs to have the smallest number of runtime dependencies as
reasonable possible (GNU M4 is a *build* time dependency, and
even that is forced on me by Autoconf).
5. When you link your project code against dependent libraries, you
should only have to specify the libraries that you use directly -
the indirect libraries should be taken care of by the operating
system, and when the OS is deficient, libtool should do the heavy
lifting.
The current implementation of GNU Libtool also has the following (IMHO
desirable) aspects, which are not immutable, but make Libtool easier to
use than it would be otherwise:
1. Once installed, it is useable outside the GNU eco-system by any
build-system that is prepared to call libtool rather than the
C-compiler for building and linking against shared compilation
units;
2. It can be used to bootstrap the C compiler (and is used by GNU
gcc in that capacity to simplify tracking all the varied options
for bootstrapping it's own runtime with the vendor compiler on all
the systems it supports).
I could probably think of others, but don't want to make this post any
longer than it already is.
I'm entirely open to reasoned criticism, and especially to useable
suggestions on how to improve the design of GNU Libtool. I probably
won't pay too much attention if you tell me that I should rewrite the
entire GNU build system and expect several thousand packages to pay
any attention to me. I only maintain GNU Libtool and GNU M4, so my
scope, and hacking time, is much smaller than that.
Thanks for reading this far!
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
