[ On Wednesday, January 26, 2005 at 11:22:12 (-0500), Todd Vierling wrote: ]
> Subject: Re: safe make replace?
>
> Speaking for yourself.  Those of us working in diverse heterogeneous
> environments have no real alternative except static linking

That's not true at all.

It really is quite trivial to get the linker/loader options right such
that a basic Makefile can work portably across all your diverse
heterogeneous environments.  Lots of us have done exactly this even long
before Automake came along

However now with GNU Automake the features you seek are far more
elegantly implemented by automake than by that horrid mess of, well,
crap, that we call "libtool".

The only "hard" part in the old days (before Automake and before the
WWW) was that most of the manual pages for different toolchains were
inaccessible to the average developer, and test environments (or eager
testers) were even more difficult to find, and there was no formal
definition of how these toolchains should be used.  Of course the
majority of that problem is non-existant if you're talking only about
your very own diverse set of systems right in your own domain.  :-)

The only semi-legitimate problem that libtool still solves somewhat
uniquely is one that is faced _ONLY_ by developers and testers (i.e. it
is not a problem that most end users should ever even have to think of),
and that's the creation of the wrapper scripts such that just-built
programs can be tested in place without first installing any shared
libraries that were also just built with them.  Even this problem
disappears though with proper re-factoring of the modules which make up
a project.  If the libraries are going to be installed somewhere, and
they pretty much have to be if they're dynamally loaded and are to be
used after testing is done, then they can be installed first without
having to initially install the programs that link to them.  The problem
also disappears with prebinding support that's activated on install.
And of course this problem doesn't even exist in the first place if the
program is relinked on install, or at least has its library runtime path
locations modified on install.


> > > but it is a good
> > > start at keeping ABI compatibility in the mind of the software author.
> >
> > I'm not so sure.
> 
> It's better than zero awareness, which is the point you're pushing.

But libtool doesn't really raise any true awareness of ABI compatabiilty
issues -- it simply creates a fog about versioning of shared libraries.

I.e. I think that any "awareness" that libtool might bring to the
average developer will be a false and misleading one.

I.e. I'm advocating that we find or create real tools that really do
help manage ABI compatability and that we promote instead of giving
false impressions about things like libtool.

Of course I'm at best preaching mostly to the choir here since the real
changes would have to come down from the GNU Auto* circles, and they're
the ones who have already been mostly responsible for foisting libtool
on everyone, like it or not.

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