Re: Libtool 1.4.3

[Russ Allbery]

Earnie Boyd <address@hidden> writes:

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

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.

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.

> FWIR, Akim and other developers tried hard to maintain [back|bug]ward
> compatibility.

Um, no.  I have a lot of respect for Akim and the other autoconf 2.5x
developers and what they've tried to accomplish, but it's very clear that
backward compatibility was not an important goal.  I highly doubt that any
even moderately complex autoconf 2.13 configure script will work in
autoconf 2.5x unless it was written by Akim.

There were a variety of reasons for breaking backward compatibility, like
choosing to clean up quoting, but that's a justification for doing it, not
an argument that it didn't happen.  It very clearly did happen.  Calling
the autoconf scripts that worked in autoconf 2.13 but not in 2.5x "broken"
is a deflection that I'd be more sympathetic to if the ways in which they
were "broken" were clearly documented in autoconf 2.13, but they weren't.
Which means that the language definition was changed (to something much
more precise, mind), not that scripts that followed the previous language
definition such as it was were broken.

All that being said, I believe that the direction taken with 2.5x was more
right than wrong.  Certainly it's a lot more pleasant and a lot clearer to
write configure scripts using the new language definition than the old one
because it's much clearer what to do at any given point to accomplish what
you want to accomplish (although the annoying cache directory and the
speed issues are a bit frustrating).  But it wasn't a backward-compatible
change.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>