Earnie Boyd <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
