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