From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30030 invoked by alias); 2 Mar 2011 12:14:35 -0000 Received: (qmail 30015 invoked by uid 22791); 2 Mar 2011 12:14:30 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_SUB_RAND_LETTRS4 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; Wed, 02 Mar 2011 12:14:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 658702BB06A; Wed, 2 Mar 2011 07:14:23 -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 ipAECM+U+mwI; Wed, 2 Mar 2011 07:14:23 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D92352BB08F; Wed, 2 Mar 2011 07:14:22 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 816711459AD; Wed, 2 Mar 2011 16:14:07 +0400 (RET) Date: Wed, 02 Mar 2011 12:14:00 -0000 From: Joel Brobecker To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: Include dir intl when building libcommon.a for gdb Message-ID: <20110302121407.GO30306@adacore.com> References: <4D6C90AC.9010003@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6C90AC.9010003@codesourcery.com> 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/msg00085.txt.bz2 > This patch is to fix this problem above. Cross build gdb for > i586-mingw32msvc. Failure goes away. Thanks. I should say up-front that I appreciate your responsiveness. It's very nice, particularly in this case where I feel the issue is becoming more urgent to fix. > gdb/ > * common/Makefile.in: Inherit CC. > * common/configure.ac (GDB_INCLUDE): Include dir intl. > * common/configure: Regenerate. Now, the bad news - Just this patch alone makes me dislike the current approach. I'm really sorry, and maybe that's because I'm not understanding all the issues, here. > diff --git a/gdb/common/Makefile.in b/gdb/common/Makefile.in > index 9230b87..23117a9 100644 > --- a/gdb/common/Makefile.in > +++ b/gdb/common/Makefile.in > @@ -26,6 +26,7 @@ COMMON_CPU_OBJ = @COMMON_CPU_OBJ@ > # CFLAGS is specifically reserved for setting from the command line > # when running make. I.E. "make CFLAGS=-Wmissing-prototypes". > CFLAGS = @CFLAGS@ > +CC = @CC@ This part looks fairly obvious, and OK to me. > diff --git a/gdb/common/configure.ac b/gdb/common/configure.ac > index 1ef85fe..b31a3e9 100644 > --- a/gdb/common/configure.ac > +++ b/gdb/common/configure.ac > @@ -63,7 +63,7 @@ if test x"$enable_gdbserver" = xyes; then > GDB_INCLUDE="-I\$(srcdir)/../gdbserver/" > else > GDB_FLAGS="" > - GDB_INCLUDE="-I\$(srcdir)/../ -I\$(BFD_DIR)" > + GDB_INCLUDE="-I\$(srcdir)/../ -I\$(BFD_DIR) -I../../intl/" > fi This part, however, makes me uncomfortable. There are a couple of reasons. The current code is: if test x"$enable_gdbserver" = xyes; then GDB_FLAGS="-DGDBSERVER" GDB_INCLUDE="-I\$(srcdir)/../gdbserver/" else GDB_FLAGS="" GDB_INCLUDE="-I\$(srcdir)/../ -I\$(BFD_DIR)" fi The first question is: I don't understand why we have different include and compilation flags. I can see how -DGDBSERVER is used to select between gdb's "defs.h" and gdbserver's "server.h". So, OK for now. But for the rest, why do we maintain different include paths depending on whether we build it for GDB or for GDBserver? It's like a circular dependency. I can explain that we need to select either $(srcdir)/../gdbserver/ or $(srcdir)/../ for the same reason as above (including "defs.h" or "server.h"). For the rest, I think that the -I flags should be the same regardless of who we build these files for. In my mind, it's supposed to be actually independent from both GDB and GDBserver. And unfortunately, right now, it is dependent on both :-(. 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. 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. -- Joel