This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Final(?) patch to update libtool in GCC and src trees
- From: Charles Wilson <libtool at cwilson dot fastmail dot fm>
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: bonzini at gnu dot org, drow at false dot org, binutils at sourceware dot org, gcc-patches at gcc dot gnu dot org, gdb-patches at gcc dot gnu dot org, newlib at sourceware dot org, Ralf dot Wildenhues at gmx dot de, aoliva at redhat dot com, fxcoudert at gmail dot com, schwab at suse dot de
- Date: Fri, 13 Apr 2007 14:44:19 -0400
- Subject: Re: Final(?) patch to update libtool in GCC and src trees
- References: <200704131824.LAA20935@hpsje.cup.hp.com>
Steve Ellcey wrote:
This feels backwards to me.
I think we should do a Src tree only patch (GCC tree doesn't need this
change) to set ACLOCAL_AMFLAGS and to remove the use of sinclude before
doing anything else with libtool.
Then, when we go to update libtool, no other changes should be needed in
the src tree. In other words, do the clean up first.
This is logical -- but I think the other posters are worried that your
existing patch has gone thru several weeks of testing, on some
non-homogeneous set of platforms/targets/configurations. Your proposed
change has not.
I suspect that if you want to pursue this order-of-commits, you will be
asked to get the "cleanup" patches validated by a similar test regime,
and that will only extend the time you must maintain the libtool-centric
patches out-of-tree.
I'll even go further and say that we should move the m4 macros that are
currently in bfd and used by other components over to the config
directory as part of this patch. These files are acinclude.m4, bfd.m4,
and warning.m4. That way we don't have to put -I ../bfd in the
ACLOCAL_AMFLAGS variable at all. We set ACLOCAL_AMFLAGS to "-I .. -I
../config" and we are done with it.
Agree with respect to bfd.m4 and warning.m4 (subject to the concerns
above). But acinclude.m4 is intended to be specific to each
independently configured project (or subproject with its own
configure.[ac|in]). That's why there are a lot of acinclude.m4 files in
the src/ tree:
-rw-r--r-- 1 cwilson None 2948 Mar 24 18:04 ./bfd/acinclude.m4
-rw-r--r-- 1 cwilson None 30 May 15 2005 ./binutils/acinclude.m4
-rwxr-xr-x 1 cwilson None 66436 Jan 14 2004 ./config/acinclude.m4
-rw-r--r-- 1 cwilson None 2658 Mar 24 18:06 ./gas/acinclude.m4
-rw-r--r-- 1 cwilson None 505 Mar 24 18:06 ./gprof/acinclude.m4
-rw-r--r-- 1 cwilson None 30 May 15 2005 ./ld/acinclude.m4
-rw-r--r-- 1 cwilson None 534 May 31 2006 ./opcodes/acinclude.m4
-rw-r--r-- 1 cwilson None 1174 May 24 2006 ./winsup/acinclude.m4
-rw-r--r-- 1 cwilson None 7319 Feb 5 17:57 ./newlib/acinclude.m4
<maybe more in modules I do not have checked out>
Frankly, The Right Thing To Do is to take each acinclude.m4, and split
them up into functionally-independent my-descriptive-name.m4's. Then,
perhaps move (common ones? identical ones that appeared in multiple
acinclude's? all of them?) into config/, do away with all acinclude.m4's
and let aclocal do its job. [caveat: except perhaps if there are any
cases where automake/aclocal are not used to maintain the existing
aclocal.m4 file; it does not appear to me that any of the components in
src/ meet that exception]
But that is an large effort, and one that is completely orthogonal to
your existing patches, and should be handled separately. And getting
modern libtool support into the tree should not be predicated on this
separate effort, IMO.
Would such a patch, done before any of the other libtool changes, be
acceptable?
See above.
--
Chuck