From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9025 invoked by alias); 28 Jan 2011 14:54:02 -0000 Received: (qmail 9008 invoked by uid 22791); 28 Jan 2011 14:54:02 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Jan 2011 14:53:57 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0SErnaL004961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jan 2011 09:53:49 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p0SErm7t028742; Fri, 28 Jan 2011 09:53:48 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p0SErlGM012864; Fri, 28 Jan 2011 09:53:48 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 9BE013784E2; Fri, 28 Jan 2011 07:53:46 -0700 (MST) From: Tom Tromey To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [rfa/rfc] Build libcommon.a for gdb and gdbserver References: <4D30E23F.3080103@codesourcery.com> <4D34C9DE.3040603@codesourcery.com> <4D375F44.70504@codesourcery.com> Date: Fri, 28 Jan 2011 15:04:00 -0000 In-Reply-To: <4D375F44.70504@codesourcery.com> (Yao Qi's message of "Wed, 19 Jan 2011 15:01:40 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-01/txt/msg00547.txt.bz2 Tom> Another idea would be to just have gdb/configure, but have a special Tom> Makefile target that only builds gdbserver. Then all the configury Tom> would be unified; maybe this is the best option, for that reason. Yao> I thought of this, but it makes gdb/configure in mess when we move Yao> everything to gdb/configure. Finally, IMO, it is better to create Yao> separate Makefile.in/configure.ac in common/, whic scales well when we Yao> move more files to common/ later. I think gdb/configure is already pretty messy. It is more than 2000 lines of code. A few more for gdbserver aren't going to hurt much, IMO. The problem I have with adding another configure script is that presumably it must arrive at all the same conclusions as both gdb and gdbserver's configure scripts. That means either maintaining things in parallel -- which will be fragile -- or putting a bunch of code into shared .m4 files. But then... why run that same code multiple times, when we can just do it once? Yao> 3. Including different headers when building libcommon.a for gdb and Yao> gdbserver. I don't understand this. I didn't see it in the patch. Yao> 4 Building libcommon.a for gdb and gdbserver respectively. This seems to mean that we must build libcommon twice. I don't understand that -- what is the benefit, versus having a single library? Yao> diff --git a/gdb/Makefile.in b/gdb/Makefile.in [...] Yao> +$(LIBCOMMON): $(LIBCOMMON_DIR)/Makefile Yao> + @$(MAKE) $(FLAGS_TO_PASS) DO=all DODIRS=common subdir_do Yao> + Yao> +configure-common: Yao> + @: $(MAKE); $(unstage) Yao> + @r=`${PWD_COMMAND}`; export r; \ Yao> + s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \ I believe gdb/configure will take care of this, because `common' is now in AC_CONFIG_SUBDIRS. Tom