From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31796 invoked by alias); 2 Mar 2011 13:12:14 -0000 Received: (qmail 31781 invoked by uid 22791); 2 Mar 2011 13:12:13 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_SUB_RAND_LETTRS4,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Mar 2011 13:12:07 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id p22DAMoD008747; Wed, 2 Mar 2011 14:10:22 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id p22DALsr026410; Wed, 2 Mar 2011 14:10:21 +0100 (CET) Date: Wed, 02 Mar 2011 13:12:00 -0000 Message-Id: <201103021310.p22DALsr026410@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: yao@codesourcery.com, gdb-patches@sourceware.org In-reply-to: <20110302121407.GO30306@adacore.com> (message from Joel Brobecker on Wed, 2 Mar 2011 16:14:07 +0400) Subject: Re: Include dir intl when building libcommon.a for gdb References: <4D6C90AC.9010003@codesourcery.com> <20110302121407.GO30306@adacore.com> 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/msg00091.txt.bz2 > Date: Wed, 2 Mar 2011 16:14:07 +0400 > From: Joel Brobecker > > > 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. This actually makes me believe that the code that's being moved to common/ should be virtually #ifdef-free.