From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10070 invoked by alias); 19 Feb 2003 12:52:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10054 invoked from network); 19 Feb 2003 12:52:13 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 12:52:13 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E0B962D37; Wed, 19 Feb 2003 07:56:59 -0500 (EST) Message-ID: <3E537F1B.2010601@redhat.com> Date: Wed, 19 Feb 2003 12:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Carlton Cc: gdb-patches@sources.redhat.com, Elena Zannoni , Jim Blandy Subject: Re: [rfc] block.{h,c} References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00398.txt.bz2 Can it eventually contain the few remaining scraps of block* code found in blockframe.c (hint, hint :-)? > I'd like to move 'struct block' out of symtab.h into a new file > block.h, and creating a new file block.c with block-specific > functions. Doing so would help lessen compilation dependencies, which > is important for people like me with slow computers: right now > symtab.h is included by around 140 files, while the resulting block.h > would only be included by around 40 or so. Basically, my code > organization philosophy says that you should only define two different > structures in the same include file if they are very closely linked > (e.g. if code that refers one would almost always refer to the other); > symtab.h doesn't pass that test. For example, there's no particular > reason why code using 'struct block' would be particluarly like to use > 'struct minimal_symbol', or vice-versa. > > I don't feel _too_ strongly about this; on the other hand, I can't see > any reason not to make this change other than inertia. (I guess that, > the more include files there are, the more possibility there is that > Makefile.in could get out of sync; that's not a good reason, though, > and maybe the ARI could check for that?) I think it is consistent with GDB's current overall direction - more modula with *.[hc] relating to specific objects or sets of objects. Andrew