Re: FYI: libtool.m4 removal problem

[Gary V. Vaughan]

Merry Christmas all!

I've just about shaken my jet lag, and in the process of reaclimatising
to British weather (cold.  wet.), so I'm making a start at working
through my list post backlogs...

Bob Friesenhahn wrote:
> On Sat, 18 Dec 2004, Daniel Reed wrote:
>
> > On 2004-12-18T11:56-0600, Bob Friesenhahn wrote:
> > ) On Wed, 15 Dec 2004, Ralf Wildenhues wrote:
> > ) >>             I will not be shipping multiple versions of Libtool, 
> > either,
> > ) >> which means we will continue shipping only out of branch-1-5 
> > until newer
> > ) >> versions accept the exact syntax used by 1.5 and earlier
> > ) > it much better to allow for parallel installations than not.  There's
> > ) > little value in having distributors work out how to do parallel
> > ) > installations if anybody needs these.  I still had the hope that we
> > ) > could just get away *without* the need.
> > ) I agree with Chuck that supporting parallel installs will help get
> > ) newer libtools into distributions faster.
> >
> > I respectfully, but authoritatively, disagree.
>  
> Within his sphere of influence, Chuck is also able to exert 
> "authoritative" and knowledgeable opinions.
>
> It seems that there is a difference between distribution maintainership 
> approaches.  Some maintainers attempt to modify each package so that its 
> build meets a particular baseline (e.g. force one version of libtoolize, 
> automake, autoconf), while other maintainers attempt to work with the 
> packages as delivered so that they require minimal modification.

One of my paying gigs is in fact as a distribution maintainer, and in 
that capacity I am in the compile packages with minimal modification
school.  As it happens, in that environment, libtool (autoconf, automake
etc.) are already parallel installed -- each with their own $prefix --
and thus aclocal has to have a carefully constructed command line search
path in order to find all the right macros, and each tool has to be
invoked with its full path.  That is, with a little work it is possible
to perform parallel installs of all these tools without any specific
support.  However, it *is* a PITA that could be significantly reduced
for future distribution maintainers by officially supporting parallel
installs so that they will be able to set up *their* environments less
painfully.

> > Being backwards compatible in syntax is worth much, much more to me, as a
> > distributor, than supporting multiple simultaneous installs.

> I certainly agree that there is substantial value to backwards 
> compatible syntax, but it does not ensure that the actual behavior of 
> the older and newer versions will be the same.

Exactly, especially considering package maintainers' propensity to make
use of undocumented features that change or disappear between autotool
releases.  And that is why I find it less risky to retool a software
package with the same autotool releases that the package maintainer
used.

Libtool can support both styles of maintainership by offering parallel
installs.  We (libtool maintainers) should not be in the business of
dictating how distribution maintainers can work.  Of course, to support
both schools, backwards compatible syntax between releases is at least
as important a goal.

That said, the current implementation is incomplete, and requires more
work than I want to back up into the 2.0 release cycle.

I would like to resolve the current issues with 2.0, and release that,
and then see whether we can get the parallel install feature on HEAD
into shape for the next release... or throw it out if it proves to be
unworkable after all.

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature