Re: <cpu>-frame.c, frame/<cpu>.c, config/<cpu>/frame.c, ...

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, May 04, 2003 at 12:41:56PM -0400, Andrew Cagney wrote:
> >On Sun, May 04, 2003 at 12:10:36AM -0400, Andrew Cagney wrote:
> >
> >>>Andrew Cagney writes:
> >
> >>> > config/<cpu>/frame.[hc]:
> >>> > Keeps the cpu stuff in a single directory.
> >
> >>
> >>Some things I forgot to note:
> >>
> >>This is actually the one I like least.  config/<cpu>/*.{mt,mh,h} are all 
> >>being deleted, so adding files to that directory would make for 
> >>confusion.  Unlike {unwind,frame}/, it isn't clear what the exact 
> >>interface that the file should be exporting was.  On the other hand, it 
> >>keeps <cpu> files together.
> >>
> >>There is the question of where to put more generic unwinders (dwarf2cfi, 
> >>libunwind, ...)
> >
> >
> >Hmm.  For non-cpu-specific files, we have two choices that I can think
> >of off the top of my head:
> >  - Toplevel directory
> >  - Functional subdirectory, i.e. unwind/ or frame/.  I rather like
> >    that idea...
> 
> This is somewhat at odds with having the CPU files, that implement the 
> exact same interface, in a separate directory.

Hmm, maybe.  I guess my preferences would be generic code in the
toplevel and cpu code in a config/cpu/ dir.  But that may be just
because I'm familiar with trees laid out that way.

> Having the CPU specific files in one place is nice if the only concern 
> is hacking on those cpu specific files.  However, when hacking cross 
> architecture (as I'm typically doing), or wanting to examine a 
> consistent set of examples for a given interface (as someone adding a 
> new architecture would be doing), then I think having a one stop 
> [directory] shop is far easier.  Having stuff scattered across many and 
> inconsistent set of directories and files is a straight pain in the bum 
> - look how often people [me] miss something burried in one of the 
> config/<cpu>/* files.

Honestly, I don't think it makes a lot of difference when hacking
cross-architecture.  I've done that in GCC from time to time; you have
to remember to use grep -r instead of grep, but otherwise it's no more
work.

You have to do it now anyway, since so much is in tm headers.

But this is mostly conjecture too.  Don't know how it would work out.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer