autoreconf vs patching

[Ralf Corsepius]

On Mon, 2005-02-14 at 08:18 -0500, Toshio wrote:
> On Mon, 2005-02-14 at 10:32 +0100, Ralf Corsepius wrote:
> Re: including patches for autotools generated files.
> > IMO, this is the only feasible approach, for 2 reasons:
> > 1. This is how the autotools are assumed to be used.
> > 
> > Packagers are not supposed to run any of them when building a package.
> > If you find you can't avoid running them, something inside of the
> > package is broken - Unfortunately there are many broken and mal-designed
> > package configurations out there :(
> > 
> Here here.  I think the problem is that autotools are the means by which
> software is made portable but most software developers have only a few
> systems types on which to develop... so it's the distro packagers of
> their software (us) that end up fixing the autotools scripts to work.
Yes, but ... how many times do you end up adjusting sources for other
tools?

The autotools are developer tools like many others, so similar to you
having to fix broken/incompatible c/c++ code, adjusting hard-coded
paths, broken scripts etc. you'll have to cope with them.

I.e. the "right way" to deal with such problems would be to get these
packages fixed upstream or not to package these packages ("We can't
package your package is broken and needs to be fixed").

> > 2. Running autoreconf is error-prone and can break packages in subtile
> > and hard to find ways.
> > 
> > In probably >> 90% of all cases it will work without too many problems,
> > but those cases it doesn't work out often are even hard to recognize.
> > (I.e. you only think autoreconf worked, while it actually failed.) 
> > 
> > When using patches, you very likely recognize these cases and will be
> > able to fix them.
> > 
> Hmm... Here's where we part ways for the time being.  Probably because
> I've only worked on those 90% of packages so far :-)
Probably :-) From the autotools' POV, probably >>90% of all packages are
trivial.

The remaining 10% can be hard, sometimes very hard.

>   If you have some
> redhat/fedora.us bugzilla entries or some examples of how autoreconf
> messes up, I'd like to look at them so I can understand how things break
> and how patching would make spotting the errors easier.
Well, it basically is a matter of complexity.

Typical examples for case when autoreconf can break things are

* Running autoreconf on configurations using advanced autoconf tricks to
setup configuration subdirectories or mixing versions of autotools
across configuration subdirs. 
Somewhat oversimplifying: Using autoreconf becomes dangerous when a
package consist of several subpackages.

* Running autoreconf will run the currently installed of current
autotools. In cases configurations have been written using
older/obsolete versions of the autotools, this can introduce behavioral
changes or even break configurations, because the autotools have changed
their behavior or because a package author might have exploited
autotools internals which meanwhile have changed.

* Running autoreconf on configurations having been created by
customized/modified/hacked autotools.
 E.g. RH's libtool is such kind of "hacked" autotool, i.e. running a
non-RH libtool on configurations having been created by RH-libtool can
break a package - Of cause this will not hit you on RH-based systems :)
However, others also use similar "modified/customized" autotools and
ship scripts having been generated by these tools, so you are likely to
trip problems related to the "hacks" they apply.

* Like any other tools, autoreconf is not bug-free. It is known to fail
due to bugs in some cases (c.f. autoconf's CVS).

If you want to see some of these problems, take a complex source-tree
and try autoreconf on them. One case to try would be running autoreconf
on packages or sub-packages from the "uberbaum", e.g. GCC, binutils,
snavigator. insight, gdb etc.

Ralf