From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Daniel Berlin Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Start abstraction of C++ abi's Date: Mon, 19 Feb 2001 14:58:00 -0000 Message-id: <3A91A4B5.36FD8BD4@apple.com> References: <3A917341.BDA8781B@cygnus.com> X-SW-Source: 2001-02/msg00385.html 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