This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Update to current automake/autoconf/libtool versions.
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Klee Dienes <klee at apple dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,"Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>,DJ Delorie <dj at delorie dot com>, binutils at sources dot redhat dot com,gdb-patches at sources dot redhat dot com
- Date: Thu, 05 Dec 2002 13:59:15 -0500
- Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
- References: <A5661C8C-087A-11D7-A7CE-00039396EEB8@apple.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