[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: an update to automake-1.11?

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.

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

I think it would be much better to ensure rerunning autoreconf will always 
just work, then upstreams wouldn't have to ship autogenerated files as 
"source code". But of course that'd turn a lot of the autotools' core design 
decisions (e.g. the idea of generating shell scripts in the first place) 
into accidents of history. So I'm sorry (and I know you'll probably never be 
convinced), but I don't think the autotools can be fixed and still be the 
autotools, the whole concept is flawed.

What I see is tarballs getting littered with generated files which are 1. 
unnecessary, as they can just be regenerated and 2. contain generated 
snippets which get old quickly. If I fix a bug in CMake, it'll automatically 
fix the issue for all subsequent builds of CMake-using software (unless my 
fix is incompatible and I have to introduce a "policy" for it, then they 
need to opt in to the fix). If I fix a bug in the autotools, some software 
may never pick it up, and the one that will may take years to pick it up! 
How is that an advantage?

        Kevin Kofler

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]