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

> > I fail to see how what is essentially a compiler wrapper script is any worse
> > off than automake makefile fragments.
>
> Oh, but if that were all libtool was.  Sigh.

Oh, but that's all libtool is.

> Have you actually dug your head into that spaghetti lately?

Yes, as a matter of fact, I have.  I happen to be the maintainer of libtool
for pkgsrc, and I've gone to some pains to make sure that any
pkgsrc-specific twiddles are m4 clean.

> It's one of the worst nightmares of self-configuring state machine shell
> script that I've ever seen.  It makes the Autoconf M4 macros look trivial.

And moving those platform conditionals to automake would make it more
"trivial" how?  Puh-leeze.  It's autoconfiguring for a reason:  platforms
evolve...

> Like I said, the X11 Imake rules have almost got it right (except for
> the fact that they come along with all the other Imake baggage).

...and imake config tends not to keep up.

Yeah, sure, the imake rules work -- and so do the Perl rules, and the
OpenSSL rules, and... see where I'm going with this?

> >  A compiler frontend script is far more flexible to use, actually;
>
> How many frontends do we have to have in front of the compiler before we
> end up with nothing but overhead?

I don't know.  Libtool, however, is certainly less overhead than most
autoconfigure scripts.  (Take Perl's, for instance.  It even has a ...
compiler wrapper ... to deal with many of the same OS dependencies.)

> > it permits usages outside the scope of
> > automake, which is too policy-foisting for many folks.
>
> I kept using the phrase "automake like" for a reason....

There isn't another such common framework that is not attached to some other
"baggage," as you put it; automake is just another one with extra baggage.

Libtool works even in existing, foreign build frameworks, including ones not
even using traditional make(1), with no extra policy baggage.  Or in other
words, it is indeed more flexible than automake and similar systems because
it doesn't even require traditional make syntax.

So we've come full circle back to:  libtool is ugly, sure, but it works,
manages to adapt a bit with the times, and actually makes an effort to
document how to handle ABI affecting events.  You seem to think this isn't
the case, but somehow you can't seem to put into words exactly why, because
all your arguments have been tangential to this original point.

Now, all of this doesn't prevent you from helping out a project that you
find to be a good substitute ("constructive" work towards an alternative).
Feel free to do so, and let us know how it turns out; it would be worth
trying out in practice, at least.

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