From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26190 invoked by alias); 18 Oct 2002 21:52:10 -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 26097 invoked from network); 18 Oct 2002 21:52:09 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 18 Oct 2002 21:52:09 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9ILq2928815; Fri, 18 Oct 2002 14:52:02 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Elena Zannoni Cc: gdb-patches@sources.redhat.com, Jim Blandy Subject: Re: [rfc] split up symtab.h References: <15792.30892.69140.402056@localhost.redhat.com> From: David Carlton Date: Fri, 18 Oct 2002 14:52:00 -0000 In-Reply-To: <15792.30892.69140.402056@localhost.redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00310.txt.bz2 On Fri, 18 Oct 2002 17:10:04 -0400, Elena Zannoni said: > I see your point. But I have to agree with Kevin about the tangled > web we could be weaving. Maybe we could start with a little > cleanup. Are all the things exported by symtab.h actually used? And > vice versa, are the files including symtab.h actually needing it? I > found a few times that some dependencies were left in place after > some code which needed them had been deleted, etc. I'll look into that. Actually, I already have one candidate for cleanup: if you do "grep 'struct source' *.h *.c", it sure looks like struct source and struct sourcevector aren't needed. (And if you add ChangeLog* to your list of files to grep, it looks even more suspicious!) So I think that's the obvious candidate for deletion from symtab.h. Also, I think that struct symbol_search could be moved to symtab.c. (Though I'd want to look into how that's being used, because I could imagine that some such structure could be useful for other files in the future.) And I'll look into the reverse problem, as you suggest, namely files that might be unnecessarily including symtab.h. Also, another thing that I thought of is that it's silly to propose breaking it up all at once. Right now, for example, I'm fiddling with 'struct block' in carlton_dictionary-branch to see how it would be a good idea to modify it to handle namespace lookup correctly. (And, unfortunately, each time I think I understand C++ name lookup rules, I get surprised by the compiler or the standard, and I realize that my data structures aren't good enough; it's definitely a good thing that I'm doing this on a branch...) So maybe, as an experiment, I'll try moving 'struct block' and 'struct blockvector' into a file "block.h", and I'll try to be careful about getting the #includes and Makefile.in just right; if it turns out to be useful, then I'll consider sending an RFA to the list. Getting just that one bit right would be a lot easier than splitting symtab.h up into 10 files, or whatever I proposed in my RFC: splitting it up all at once is just asking for trouble. David Carlton carlton@math.stanford.edu