On Fri, 28 Jan 2005, Greg A. Woods wrote:

> > ...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.

I've worked with much more than eight platforms -- I was referring to eight
different types of shlibs with different link procedures (not just different
"link options").  If I include the variants on iBCS2, Sun-style, ELF, and
PE-COFF, the list would get much longer.  And yes, that list gets far too
long to maintain on a per-project basis.

> 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.

I fail to see how what is essentially a compiler wrapper script is any worse
off than automake makefile fragments.  A compiler frontend script is far
more flexible to use, actually; it permits usages outside the scope of
automake, which is too policy-foisting for many folks.

> 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.

If you track back, this ranting about libtool's [perceived, by you]
shortcomings was your posit, and my main point in response (before I went
into troll-feeding entertainment mode) was that it provides, today, a
workable solution that actually puts an effort forward to document when to
deal with different types of ABI changes.  It's at that point that you
decided to ignore that point entirely and go off on the tangent of
destructively bashing libtool rather than doing something constructive with
your idea....

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>