From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12911 invoked by alias); 3 Mar 2011 03:15:43 -0000 Received: (qmail 12902 invoked by uid 22791); 3 Mar 2011 03:15:42 -0000 X-SWARE-Spam-Status: No, hits=-1.4 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; Thu, 03 Mar 2011 03:15:36 +0000 Received: (qmail 14826 invoked from network); 3 Mar 2011 03:15:34 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Mar 2011 03:15:34 -0000 Message-ID: <4D6F07D2.8050004@codesourcery.com> Date: Thu, 03 Mar 2011 03:15:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org, Joel Brobecker Subject: Re: Include dir intl when building libcommon.a for gdb References: <4D6C90AC.9010003@codesourcery.com> <20110302121407.GO30306@adacore.com> <4D6E5854.4020103@codesourcery.com> <201103021532.02784.pedro@codesourcery.com> In-Reply-To: <201103021532.02784.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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/msg00152.txt.bz2 On 03/02/2011 11:32 PM, Pedro Alves wrote: > On Wednesday 02 March 2011 14:46:44, Yao Qi wrote: >> To your first question, because common/signals.c uses "ifdef GDBSERVER", >> which makes a lot troubles here. I think of this problem again, and >> find that root cause of this problem is that files in common dir >> includes some gdb-specific or gdbserver specific code. > > You're oversimplifying. You'll need to include one or the > other in files under common/ that require types such as CORE_ADDR > and others. Obvious solutions to that are to rename server.h to > defs.h, or add a new defs.h that just includes server.h. > I don't understand why it is "oversimplying". We should make code in common/ dir as "common" as possible, and don't need conditional includes and flags. This approach meets needs so far, since there is only one c file in common dir, and doesn't require types such CORE_ADDR. When we moving more and more files to common/, we should move some common types, like CORE_ADDR, into common as well. > I haven't seen any comment on AC_CHECK_HEADERS concerns > I raised, probably because the FSF tree has only signals.c > and not much else under common/ currently, which hides > the issue. > > Grepping the code we have under common/ in our local tree > for "HAVE_", I see: > > $ grep HAVE_ * > gdb_dirent.h:#ifdef HAVE_DIRENT_H > gdb_dirent.h:# ifdef HAVE_SYS_NDIR_H > gdb_dirent.h:# ifdef HAVE_SYS_DIR_H > gdb_dirent.h:# ifdef HAVE_NDIR_H > gdb_locale.h:#ifdef HAVE_LOCALE_H > gdb_locale.h:#ifdef HAVE_LANGINFO_CODESET > signals.c:#ifdef HAVE_SIGNAL_H > > Maintaining and making sure these checks are in both configures, > rather than centralized is harder than updating two Makefiles. > IMO, this should be handled by an .m4 under common that is > used by both configures, something like gnulib/'s gl_INIT. Yes, .m4 file can reduce duplication of configures in both gdb and gdbserver. I agree. > gnulib does not have its own configure, yet it integrates into > random configures. It looks like a better model for common/ > to me. We can have configure/make and .m4 together in common/. .m4 file provides common macros, while configure generates Makefile for source in common/. -- Yao (齐尧)