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

Re: an update to automake-1.11?

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
are still abusing the autotools.

s/ab// ;-)

Why can't we just move to a better build system with higher focus on
backwards compatibility?

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 endoframe com>
<http://endoframe.com>               Jabber: <braden jabber org>

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