Hello, Russ! I'm the one who suggested the version 2.50 when it was discussed whether the next version should be 2.14, 2.15 or 3.0. The reason was because there was some incompatibility, but not significant to justify the major number change.
It is possible to write configure.in compatible with 2.13 and 2.5x. Whether is was possible to write a 100% correct configure.in that would work with 2.5x before the 2.50 release is a big question, because the documentation was hard to understand. I think that it was possible, although some understanding of m4 was required in addition to the old Autoconf manual. Plus clean hands, of course, which means doing thing right, and not just adding quotes until it works. > > Two wrongs a right does not make. I.E.: I believe it wrong for any > > maintainter to not move forward with the current versions of autotools > > regardless of the maintainer's reasons for not doing so. > > That comes across as pretty arrogant. It may be arrogant, sure, but in the case of Autoconf it's indeed time to move forward. > autoconf 2.5x was a disaster for some projects. That it was a disaster > because autoconf 2.13 was woefully inadequate and therefore they had to > do things they shouldn't have to do to accomplish what they needed to > accomplish doesn't change the fact that autoconf 2.5x was a disaster and > represents a vast amount of work that would have to be done. At least 75% of that is the work that should have been done before, i.e. underquoting. > Many projects have other priorities, since after all autoconf 2.13 was > working for them. The vast majority of packages using autoconf have not > updated to autoconf 2.5x in my experience with compiling software. Mind you, Autoconf-generated scripts are meant to work not just for maintainers. They are meant to work for users. One hour spend by a developer is nothing compared to 1000 users downloading bash just to run that damned configure script and 10000 users giving up. New versions of Autoconf are more portable. If libtool 1.4.3 is going to provide compatibility with MacOS (i.e. zsh, if I understand correctly), then it's absolutely reasonable to require the developer to spend some time and make sure that the configure script provides the same level of compatibility. -- Regards, Pavel Roskin _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool