Re: [RFC] Update to current automake/autoconf/libtool versions.

[Zack Weinberg <zack@codesourcery.com>]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> Accordingly, I suggest getting clean patches for small sets of 
> directories, making sure they work, getting them reviewed, and then 
> putting them in; and then starting on the next set.  Keep sending update
> notices to the various lists regarding which directories use the 'new' 
> tools and which use the 'old'.  If you can make scripts which work 
> correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means 
> do so *first*, and mark those scripts as "compatibile with both", of 
> course; but I expect that will only happen for the simplest directories.

I'd like to remind everyone involved that last I checked it was flat
impossible to do what libstdc++-v3/configure.in needs to do, using
autoconf 2.5x.  I am not particularly sanguine about the situation
having changed, since it involved the undocumented AC_NO_EXECUTABLES
macro that as far as I know nobody but us has a use for -- and we're
not using it, because it doesn't do what we need it to do.  Until that
is resolved, which will involve submitting patches to autoconf,
getting them accepted upstream, and waiting for a release, gcc
*cannot* move to autoconf 2.5x.  We are not being stick-in-the-muds
because we want to.

(Please, I beg of you, prove me wrong about this problem.)

I am concerned about the prospect of having the src repository update
to 2.5x while the gcc repository is still stuck with 2.13.  Having
different parts of the combined tree need different versions of
autotools is a recipe for disaster.

But I do see a way forward.  It goes like this.  One directory at a
time, we go through and do whatever it takes to get that directory's
configure.in to work properly with both 2.13 and 2.5x, independent of
what version of autoconf was used to generate configure in other
directories.  This may involve submitting patches to the autoconf
maintainers.  Whoever volunteers to do this must be willing to
maintain these scripts in that state indefinitely -- I did it for the
gcc subdirectory a year or so ago and I discovered a couple weeks back
that it had mysteriously broken.

Once the entire tree makes it into this state, we have a flag day
where we bump AC_PREREQ and regenerate everything.  And only then can
we start using 2.5x specific features in configure scripts.

As for libtool and automake, my suggestion is, as usual, that both
should be eradicated from the face of the Earth; as this proposal is
probably a non-starter, I decline to discuss what to do with them any
further.

zw