an update to automake-1.11?

[Braden McDaniel]

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