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

[Klee Dienes <klee at apple dot com>]

On Monday, December 30, 2002, at 02:41 PM, Alexandre Oliva wrote:

> 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.
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:

http://sources.redhat.com/ml/binutils/2002-12/msg00293.html

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).

> > 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.
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 
tagged configurations.

> > 	* .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.
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.

> > 	* 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.
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).

> > 	* 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
> instead.
configure is generated automatically now, but it wasn't when I prepared 
this patch.

If you look at the second patch I prepared 
(http://sources.redhat.com/ml/binutils/2002-12/msg00293.html), you'll 
see that I learned the error of my ways (as defined by 
http://sources.redhat.com/ml/autoconf/2002-02/msg00059.html), and 
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.