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@xxxxxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
