Re: [PATCH] Start abstraction of C++ abi's

[Stan Shebs <shebs@apple.com>]

Daniel Berlin wrote:
> 
> [...] Why is it necessary to have a long discussion
> about creating a directory for a bunch of related files? I'm happy to
> see if anyone objects, but I don't see it as a significant change.
> Maybe this is why it never gets done.

Having sources in a subdir can be a significant pain for building
if done wrong.  It also breaks people's search patterns and scripts
that look for stuff.  So what's helpful for you may be a hindrance
for somebody else.

> if you really want me to dirty the root directory with these new
> files, i will, but i felt it made a lot more sense not to.There are
> currently over 400 files in the root gdb directory. Besides the -nat
> and -tdep files, I can't tell what a file does from it's name, because
> they aren't logically divided into subdirs by functionality, and there
> are just too damn many files.  Not that I expect to see this happen,
> but to prove a point:
> Quick, what's kod.h?

Kernel object display header file...

> ocd.c?

On-chip debugging support...

> stuff.c?

Stuff that probably should have been deleted long ago, but I wasn't sure
whether it was used by anybody or not. :-)

> Can you tell that ppc-bdm.c is related to ocd.c?

Sure, because BDM is Motorola's version of OCD. :-) :-)

This isn't so much an argument for subdir organization, it's an argument
to keep the number of files down and to give them good names.  Your
examples are also a good argument for public discussion prior to
creating directories and files, since bad choices will confuse future
implementors, as you've just noted.

I will cop to being one of those who've tended to discourage subdirs
for GDB sources.  Ironically, this is not because I like flat layouts
(for Xconq, I put *everything* in subdirs), but because GDB's current
build machinery heavily favors flatness in the way that it works with
files.  Some of this is simply historical - GDB originally had literally
everything in the one dir, and years ago Fred Fish moved target config
files to subdirs.

So if someone were to come up with a good design for repartitioning
GDB sources, *and* were to follow up by implementing it, as Fred did,
I think a lot of people would support it.  If it's possible to
implement the design incrementally, that's OK too, but I'd like to
know that there is a well-defined end state, so that the sources don't
end up in a sort of half-organized mush.

Stan