From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9755 invoked by alias); 1 Mar 2011 04:42:05 -0000 Received: (qmail 9747 invoked by uid 22791); 1 Mar 2011 04:42:04 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Mar 2011 04:41:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DD2E02BAE19; Mon, 28 Feb 2011 23:41:57 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OJVq6XiqifvM; Mon, 28 Feb 2011 23:41:57 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 670D22BAD8E; Mon, 28 Feb 2011 23:41:57 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 53B1E145A56; Tue, 1 Mar 2011 08:41:44 +0400 (RET) Date: Tue, 01 Mar 2011 04:42:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Yao Qi , Pedro Alves , gdb-patches@sourceware.org Subject: Re: [rfa/rfc] Build libcommon.a for gdb and gdbserver Message-ID: <20110301044144.GH30306@adacore.com> References: <4D550834.6080807@codesourcery.com> <4D55FAB4.7090001@codesourcery.com> <4D648A5F.8050607@codesourcery.com> <4D65D5B7.1000902@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-03/txt/msg00015.txt.bz2 > Yao> Personally, I still prefer a separated configure/makefile in common/, > Yao> because, > Yao> 1. if my patch works, configure/make is not a problem, > Yao> 2. if we look forward, there should be quite a few *.c and *.h files in > Yao> common in the future. Write rules in both gdb/Makefile.in and > Yao> gdbserver/Makefile.in doesn't scale. > > I think the most important thing is that if you want to keep the > common/configure stuff, then please fix the existing problems that have > been reported. Maybe it is just the GNU make-ism at this point, I > haven't kept track. On my end of things, I actually do not like the multiple layers of miniature configure scripts. These things just keep doing the same checks over and over for the most part. It's particularly visible on Windows, were configure takes ages because spawning a script is utterly inefficient. (and as such, Tom's proposal to remove the configure script in gdb/testsuite seems like a good idea to me too) That being said, as long as it works, it's not of uber importance to me but I am not certain that argument number 2 above from Yao really is that much work. So, if we fix things fast, I do not mind continuing with the present approach. (does anyone know what the remaining issues are, though?) -- Joel