This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Start abstraction of C++ abi's
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