From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16831 invoked by alias); 13 Apr 2007 18:45:11 -0000 Received: (qmail 16782 invoked by uid 22791); 13 Apr 2007 18:45:07 -0000 X-Spam-Check-By: sourceware.org Received: from out4.smtp.messagingengine.com (HELO out4.smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Apr 2007 19:45:02 +0100 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 8DEBA21774A; Fri, 13 Apr 2007 14:45:00 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 13 Apr 2007 14:45:00 -0400 Received: from [127.0.0.1] (user-0c6suln.cable.mindspring.com [24.110.122.183]) by mail.messagingengine.com (Postfix) with ESMTP id 3491517F89; Fri, 13 Apr 2007 14:44:59 -0400 (EDT) Message-ID: <461FCF83.10103@cwilson.fastmail.fm> Date: Fri, 13 Apr 2007 20:19:00 -0000 From: Charles Wilson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Steve Ellcey CC: bonzini@gnu.org, drow@false.org, binutils@sourceware.org, gcc-patches@gcc.gnu.org, gdb-patches@gcc.gnu.org, newlib@sourceware.org, Ralf.Wildenhues@gmx.de, aoliva@redhat.com, fxcoudert@gmail.com, schwab@suse.de Subject: Re: Final(?) patch to update libtool in GCC and src trees References: <200704131824.LAA20935@hpsje.cup.hp.com> In-Reply-To: <200704131824.LAA20935@hpsje.cup.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00211.txt.bz2 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 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