an update to automake-1.11?

[Braden McDaniel]

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 at endoframe.com>