On 7/6/09 6:29 PM, Matthew Woehlke wrote:
Ralf Corsepius wrote:
Kevin Kofler wrote:
Ralf Corsepius wrote:
a) it will cause some moderate stir-up to those packages whose
upstreams
are still abusing the autotools.
s/ab// ;-)
Why can't we just move to a better build system with higher focus on
backwards compatibility?
Because
a) the autotools are not as bad as you in your want to make them appear.
Sorry, but any build system where you can't patch the build system
without risking the sky falling *is* that bad.
Why is it that to build a cmake-based project, it is a given that I run
cmake, but to build an autotools-based project, I am expected to fear
and dread and avoid-at-all-costs running autotools? Do you /really/,
honestly not see anything wrong with that?
As Conrad noted, "[the] phobia of regenerating an auto-generated script
just goes to show how completely broken autotools is."
The problem is not the sky falling, which is quite unlikely. The
problem is that when you regenerate configure and Makefile.in, you are
changing files that are part of the upstream deliverable. And you're
doing so in a less-than-surgical way that may have unintended consequences.
The situation is similar to regenerating documentation (that was already
included in the upstream distribution). Unless you are certain that you
are using the same versions of tools used by upstream, it is awfully
hard to be confident that your doc generation toolchain is
bugwards-compatible with upstream's. You probably won't get any error
messages--but you cannot be confident that the output has been rendered
as upstream intended without some very careful inspection of the output.
The difference between regenerating the build system and regenerating
documentation is that the former is irrelevant once you've successfully
built the package. If you get to that point, the way you got there
should have no impact on end users.
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. 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. However, it is quite a bit more difficult to
insulate against package maintainers determined to defeat such measures.
Regenerating the build system is the antithesis of providing surgical
patches to solve a problem. More often than not in package maintenance,
"nuke 'em from orbit" is *not* the *only* way to be sure.
--
Braden McDaniel e-mail: <braden@xxxxxxxxxxxxx>
<http://endoframe.com> Jabber: <braden@xxxxxxxxxx>
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
