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 > [EMAIL PROTECTED] > http://www.simplesystems.org/users/bfriesen > > _______________________________________________ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool