Re: Final(?) patch to update libtool in GCC and src trees

[Charles Wilson <libtool@cwilson.fastmail.fm>]

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