This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Update to current automake/autoconf/libtool versions.
- From: Klee Dienes <klee at apple dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>,binutils at sources dot redhat dot com,gdb-patches at sources dot redhat dot com,gcc at gcc dot gnu dot org,newlib at sources dot redhat dot com
- Date: Tue, 31 Dec 2002 20:16:06 -0500
- Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
On Monday, December 30, 2002, at 02:41 PM, Alexandre Oliva wrote:
Yes, my bad: at the time I had hoped to keep the changes contained to
the gdb/binutils side of the source tree. I did end up following up
with a revised patch to the gcc and newlib mailing lists, though, which
is probably a more interesting patch to comment on regardless:
Sorry I'm a bit late in following up. I don't follow these lists as
closely as GCC, and this should have been copied there, at least for
the parts that affects the top level, since those are shared.
I'm currently preparing a patch to update the gcc directories (boehm-gc
fastjar gcc libf2c libffi libjava libobjc libstdc++-v3 zlib) as well,
but it'll probably be another day or two before it's ready for posting
(the automake conversion is being particularly troublesome).
Yes, I discovered that when I went to update the gcc directories to
autoconf-2.57. I've since updated to the current libtool top-of-tree
(1.4e-1.1168 2002/12/21), since no currently released libtool supports
ltmain.sh (GNU libtool) 1.4.3
Can't do that. The copy we use is from a newer code base than the 1.4
branch of libtool. It's taken from a 1.5-to-be (multi-language)
branch from quite a while ago, back when the ltcf-*.sh scripts hadn't
been merged into libtool.m4.
I could certainly agree that autom4te.cache is an aberration, but I'm
not clear why it's inappropriate to filter it out from the CVS
repository. For those who do use it, it's nice to have not showing up
in diff and update operations, and for those who don't, the existence
of the rule does no harm.
* .cvsignore: Add autom4te.cache.
Please don't. autom4te.cache is an aberration. It shouldn't be
created by default, and it shouldn't be left dangling there in the
source tree. I'd much rather have rules that remove it as soon as
configure is rebuilt.
Given that in theory anyone running aclocal or autoconf should be
running "official" and well-defined versions of those tools, they
should also be getting correct values for the contents of libtool.m4.
If their installed libtool.m4 is incompatible with the shipped
ltmain.sh, who is to say that their installed acgeneral.m4 won't be
incompatible with a shipped libtool.m4? I'd argue that libtool.m4 is
part of the autoconf environment, and that we should just require
people running aclocal or autoconf to have the correct installations of
the tools (as in theory we already do).
* acinclude.m4: Remove include of libtool.m4.
Can't let you do that, Dave. This causes us to use whatever
libtool.m4 happens to be in aclocal.m4's search path, which is very
likely not compatible with ltmain.sh from the top level. That's why
we use libtool.m4 from the top level and keep all the libtool files in
sync. I wouldn't mind updating to the libtool current CVS tree, which
would get us rid of a number of files in the top level, but this takes
a lot of testing on many different platforms.
configure is generated automatically now, but it wasn't when I prepared
* configure.in: Use AC_PROG_LEX instead of AM_PROG_LEX.
* configure: Pass --build=$host_alias to sub-makes if no other
value is specified.
Huh? configure is generated from configure.in. Besides, it's wrong
in principle. --build is not to be the same as --host, it's the other
way round (even though autoconf 2.13 got it backwards). Gotta find
out why we depend on build being defaulted to host and fixing that
If you look at the second patch I prepared
see that I learned the error of my ways (as defined by
updated the top-level configure to only pass --build, --host, and
--target when explicitly told to by the user (and updated the
sub-configures to behave properly in response to that).
This patch is now broken as of the autoconfiscation of the top-level,
which unfortunately reverts to the previous behavior of passing
--build, --host, and --target down to the sub-configures at all times.
I'm working to make a patch for this, but am still caught up on
updating the GCC directories to work properly with automake-1.7.2, so
it will probably be another day or two.