Re: [rfc] split up symtab.h

[Kevin Buettner <kevinb@redhat.com>]

On Oct 8,  1:14pm, David Carlton wrote:

> I'm sick of having to recompile half of GDB every time I touch
> symtab.h.  There's lots of different things in that file; it's
> included in 137 different places (counting only the gdb directory, not
> gdb/mi, etc.), but there's no one thing that it defines that is used
> in more than 71 places, and a lot of things that it defines are used
> in a lot fewer places than that.

[...]

> Anyways, if anybody else is similarly annoyed with symtab.h then I'll
> try to split things up and make a more concrete RFA in a bit.

Aside from the build time issue, are there other reasons why splitting
up symtab.h is desirable?

Here are several reasons for not splitting it:

1) The list of includes for many .c files will (I suspect) grow
   quite a bit.  If it turns out that you'll be replacing one
   #include statement with five or size (per source file), I
   can't really see that making the split was an advantage.

2) One could argue that modifying symtab.h *should* be a heavy weight
   operation.  I.e, you're modifying something that's at the very
   heart of gdb and you need to take great care.

3) Makefile.in maintenance becomes harder due to the larger
   number of header files.

I should note that I don't find any of the above reasons to be
overly compelling.  I just think that we need a better reason
for making such a split than the build time consideration.

Kevin