From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1897 invoked by alias); 2 Mar 2011 12:44:08 -0000 Received: (qmail 1887 invoked by uid 22791); 2 Mar 2011 12:44:07 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SARE_SUB_RAND_LETTRS4,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Mar 2011 12:44:03 +0000 Received: (qmail 31749 invoked from network); 2 Mar 2011 12:43:59 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Mar 2011 12:43:59 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: Include dir intl when building libcommon.a for gdb Date: Wed, 02 Mar 2011 12:44:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) Cc: Joel Brobecker , Yao Qi References: <4D6C90AC.9010003@codesourcery.com> <20110302121407.GO30306@adacore.com> In-Reply-To: <20110302121407.GO30306@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103021243.58226.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00088.txt.bz2 On Wednesday 02 March 2011 12:14:07, Joel Brobecker wrote: > This definitely makes me rethink the way we approached the problem. > By taking what we have now, and moving it to common/, we drag some > dependencies which I think we do not want. I think we should either > strive to remove these dependencies as fast as we can, or use an > approach where we go the other way: Start with the foundations, and > then implement the things we are trying to move to common/ using > that foundation. For instance, defs.h versus server.h. It's tough > right now, because defs has more than just definitions. We could > isolate the part that provides the common non-GDB-specific definitions > into a common/common-defs. Thank you. +1. I said something like that from the beginning, but I didn't imagine that a configure&make under common/ sooner than later would actually make our lifes complicated. I have since learned, and I believe it was a wrong step to make. I'd much rather we were spending energy on that foundation rather than on the build, when we have only a handful of files to share at this time. > In the meantime, one proposed easy way out that doesn't destroy > all the work that has been done so far is to add all the -I > directories regardless of who we build libcommon for. I think > it makes sense from a conceptual point of view, and it will also > help us avoid maintaining 2 lists. But maybe it doesn't work for > practical reasons. gdbserver does not depend on bfd. It's wrong to leave it in the include path. gdbserver is not using gnulib either (memmem.o hack doesn't count), so there goes another include path that should not be present on gdbserver's common/ build, and should be on gdb's common/ build, but isn't at present, I think. That's a bug, and it will show its face as soon as something under common/ needs to include a gnulib header on some host (it may already, haven't checked, linux hosts doesn't need any at present). -- Pedro Alves