Re: Libtool 1.4.3 - unsolvable issue

[Allan Clark (rply to list pls)]

Libtool-ers;

I think this issue simply becomes mired by stacking up on either side of
a "for/against" line.

Previously, it was mentioned that certain troublesome source trees be
used as litmus tests for automake or autoconf changes; the same may hold
true now for libtool.  Brief summary: if you feel that your configure.ac
(or .in) represents a very complete coverage of autoconf macros, or
represents a number of things that will become incompatible when moving
from 2.13/1.4.2, then offer your project as a test-case for auto tools.

An alternative is to make the change and, as is done in many
sourcebases, release tool-X.Y.Z-pre releases to confirm that you can run
on this new set of macros/rules/environment.  If it doesn't work, post
the URL of your sourcebase, and maybe someone here will help you
modernize/adapt.

I SAY AGAIN: you might get help.  That sometimes happens in this
community.  :)


We all see the benefit of using new/standard features in the tools which
were individual kludges and hacks before; we all realize that --
especially if you have not kept current simply because the older
releases have worked for you -- it will be difficult to adapt to a
significant change.

Perhaps we (automake,autoconf,libtool) need to know what problems you're
having with a PRE release before we can really gauge the effort to keep
you working with the tools.


I strongly recommend looking at a preliminary cut.  Call it
libtool-1.4.3, and make it a CVS rollup without significant engineering
effort.  Let's test that, get some feedback, and start to contructively
work around these problems.

More of us could end up with 12-line configure.ac files.

That's my rose-coloured-glasses viewpoint.  Yeah, it's gonna hurt.

Allan




Bob Friesenhahn wrote:
> 
> On Tue, 8 Oct 2002, Thomas E. Dickey wrote:
> 
> > > > I agree.  I can't imagine why anyone would want to use an antique
> > > > version of Autoconf which dates from 1996.
> > >
> > >  Because it works? In any case, it's the respective maintainer's choice.
> > >
> > >  Making autoconf incompatible with previous versions of itself while not
> > >  upping the major release number at the same time was a pretty bad move 
> > > IMHO.
> >
> > Deliberately introducing design incompatibilities simply encourages people
> > to use other tools.
> 
> I developed/maintain the configure script for ImageMagick.  While the
> total lines in the generated configure script is meaningless, it is
> less than 1/2 of what you report for PHP, and PHP's configure script
> is 4-8X larger than typical configure scripts for other large packages
> (e.g. 4X larger than the configure script for OpenSSH).  This seems
> odd to me.
> 
> Having adopted every new Autoconf which has been released, I can
> happily say that as long as you avoid using undocumented Autoconf
> internals, it is not particularly difficult to make the minor
> modifications required to stay current.
> 
> I don't believe that the decision by some factions to stick with a
> particular Autoconf software version for the rest of time should be
> allowed to hinder the development of Libtool.
> 
> Bob
> ======================================
> Bob Friesenhahn
> address@hidden
> http://www.simplesystems.org/users/bfriesen
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool