[ On Thursday, January 27, 2005 at 17:04:13 (-0500), Todd Vierling wrote: ]
> Subject: Re: safe make replace?
>
> ...this is completely wrong, and reflects your lack of diversity experience.
> I work regularly with *eight* different platforms that have completely
> orthogonal shlib creation processes and ABI compatibility issues,

You have no idea what you're talking about w.r.t. my eperience.

This one-upmanship B.S. you're trying to pull is really rather silly,
but I'll bet I've dealt with far more object and shlib formats, never
mind completely different compilers, over my years than your eight
current platforms use, even if they do all use their very own unique
compiler and toolchain.  That's only a fraction of the varied types of
different systems I've worked with over time, and at least an equivalent
number had shared libraries to deal with.

> and
> maintaining that manually would be a real man-hour consuming task.

One whole man-hour!  wow!  Complicated!  :-)

> Had you worked on more diverse environments, you would have known the
> per-platform maintenance effort required to get shlibs right -- and hence,
> you would have known why libtool fills that niche quite well.

Do you have any idea what's involved with buidling the old SysV kernel
based shared libraries?  Linker options are only a tiny fraction of the
problem there.  Have you ever written an SysVr3 linker map file?
Dynamically From a makefile?  And DLLs under the old Windows-2.1 were
something else entirely yet again.  It really does not get any more
diverse than that.

Having been inside both libtool and the X11 Imake configs more than once
myself I do in fact know that what they do and how they do it and I know
that it would not be difficult at all to translate all the varied
shilb-handling logic they embody into makefile fragments that would
easily be managed by something like automake.  X11 Imake rules almost do
it right already, at least for building libraries, though it drags a lot
of ugly baggage around too, but I count 13 unique environments supported
there.

Libtool is just a crutch -- and a very ugly, wobbly, and wormy one at that.

It doesn't do anything magic -- it just has a very poor and overly
complex framework for encoding a bunch of rules, rules that can be just
as easily encoded directly into portable makefiles, especially with the
help of an enhanced make language/front-end like that of Automake.

Libtool's excessive complexity is driven by requirements that simply
don't apply in a surprisingly large number of situations.

Besides, I'm obviously not talking about every developer rolling their
own build rules -- just about unrolling the existing ones from libtool
and making them _easier_ to maintain, but just as easy to share between
projects.

But it still wouldn't make it any easier for pkgsrc maintainers to know
whether or not a new shared library had a truly backwards-compatible ABI
with the one that should replace it.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>