On Tue, 2009-07-07 at 02:02 +0200, Kevin Kofler wrote:
Braden McDaniel wrote:
> The number of people chiming in on this thread to the effect, "I've
> regenerated configure/Makefile.in for years and I've never had a
> problem," is testament to the fact that backward compatibility of
> autotools releases has gotten a lot better in recent years. The
> autotools are hardly unique in experiencing such growing pains during
> maturation.
Then how come CMake manages to provide near-100% backwards compatibility? Of
course, no software is perfect, but CMake's design is to be completely bug-
for-bug (*) compatible with the original version the project used (see also
the CMake policy system), whereas the autotools are doing incompatible
changes in a way which require the sources to be changed.
(*) of course only where the bugfix actually causes compatibility issues!
Otherwise they just fix it.
Breaking compatibility with previous versions of automake, autoconf, or
libtool has no impact on released tarballs made using those tools; they
continue to work as intended because they do not depend on the presence
of these tools. As such, I imagine the autotools maintainers do not
feel so great an obligation to backward compatibility as the CMake
maintainers might.
> Where they do differ from a tool like cmake is that they
insulate packages
> against future changes to the autotools themselves by avoiding any
> requirement that they (the autotools) be invoked when building the
> package.
And that's bad because there's no plan B: incompatible changes are made
(even fairly recently, see libtool 2.1) without providing backwards source
compatibility, relying entirely on tarballs shipping generated files for
backwards compatibility.
That is the use case for the tools. As with most software, little to no
support is provided for those who misuse it. This is not especially
surprising.
This is unhelpful because it doesn't help the
developer (upstream developer, packager etc.) who needs to edit the actual
source code (and this is the reason why we're having this discussion in the
first place), it doesn't help for things like snapshot checkouts from
repositories which don't carry generated files (but only generate them for
release tarballs, a fairly common practice) and of course it doesn't help if
upstream doesn't ship generated files at all (though the autotools
discourage that).
Nor is it any hindrance in these endeavors.
The autotools are well known not to make tea, either. And astoundingly,
I know of no plans to correct this.
--
Braden McDaniel <braden(a)endoframe.com>