Status of libtool 2.2.X?

[Braden McDaniel]

On Sat, 2008-10-11 at 08:17 -0700, Dan Nicholson wrote:
> On Sat, Oct 11, 2008 at 3:21 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> > On Fri, Oct 10, 2008 at 05:20:30PM -0400, Braden McDaniel wrote:
> >> A copy of the libtool script is typically included in a package.
> >> Breakage such as that patch fixes would only be incurred if
> >> libtoolize/autoreconf were run as part of the build process--something
> >> that simply shouldn't be happening in general for RPM builds.
> >
> > If I parse that correctly, are you saying that autoreconf *shouldn't*
> > be run as part of an RPM build?
> 
> That's what he's saying. The main goal of the autotools is that the
> package comes to you ready to build with just basic unix tools: shell,
> make, compiler/linker. So, you tend to not want to try to regenerate
> the build files on your own. Especially since the procedure some
> projects use can be fragile at best. autoreconf usually does the right
> thing, though.
> 
> > I have found that it sometimes needs autoreconf if I patch the
> > configure.ac script -- something which happens rather more frequently
> > when porting to MinGW.  (After these patches go upstream then it won't
> > be a problem of course).
> 
> You always need to run autoconf again if you've patched the
> configure.ac file, or nothing happens. You can run autoreconf locally
> and add the regenerated configure/aclocal.m4 to your patch, but it
> will be severely bloated.

There's no reason to patch aclocal.m4 or configure.ac at all.  You only
need to patch configure.  While that patch is likely to be bigger than a
patch to configure.ac, calling it "bloated" is a gross exaggeration.

> I tend to think it's not bad to regenerate the autotools. It's usually
> cleaner and more robust to just fix the files at the source (like
> you're doing) than to try to hack around it.

I'm not sure how modifying files unnecessarily, pulling in additional
dependencies, and making builds take longer is "cleaner", but that's
subjective.  It is certainly *not* "more robust".  By rebuilding
configure with potentially different autotools than the upstream
developer used, you expose the package build to potential
incompatibilities and breakage.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>