This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

I actually found the files in 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  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 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]