This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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: Final(?) patch to update libtool in GCC and src trees


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


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