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

[Andrew Cagney <ac131313@redhat.com>]

> I actually found the files in ftp://sources.redhat.com/pub/binutils to be an impediment to using the correct versions.  For a long time I had no idea they even existed, and then once I found out about them, it was even more confusing, since they weren't the versions that were actually used.

As a maintainer you should bring peoples attention to the fact that they 
used the wrong autoconf the moment you notice it.

> I'd argue that we should:
> 
> 1) Specify the versions of autoconf/automake/libtool/gettext by reference to official tarballs from ftp.gnu.org.  In general, define the version used to be "the most recent officially released version of each tool".

Reality check.  If the offical autoconf has a bug, GDB and BINUTILS will 
be forced to use a local version :-/

> and either
> 
> 2a) Consider updates to generated files caused by re-configuring with the most recent released version of the tools as an "obvious fix".

This is already the case.  However, it doesn't address the problem of an 
erant maintainer.

> or (even better)
> 
> 2b) Configure the CVS repository to run autoreconf using the most recent versions whenever a new configure.in/Makefile.in/Makefile.am is committed.

No.  That discussion was considered for GDB and indent.  Here the 
problem is in maintainers being able to follow a procedure.  Not a need 
for a new tool.

> The idea here is that it's relatively straightforward for a binutils/gdb maintainer to know what to do when updating a configuration file (get the most recent version of the tools from the FSF and use them), and that we have a natural tendency to stay up-to-date with automake/autoconf changes, without having flag-day style upgrades become an issue.

Andrew