Re: [PATCH] Refactor common/target-common into meaningful bits

[Pedro Alves <palves@redhat.com>]

On 08/05/2013 08:20 PM, Mark Kettenis wrote:
>> From: Tom Tromey <tromey@redhat.com>
>> Date: Mon, 05 Aug 2013 13:11:58 -0600
>>
>>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>>
>> Pedro> I've read your email several times over, and I sense that we're
>> Pedro> talking past each other.
>>
>> Yeah.  And thanks for your follow-up, I think it is clarifying.
>>
>> Pedro> Yep.  So, if we move the classic "target" bits to a "target/"
>> Pedro> module directory, and put the native bits in their own dir, we
>> Pedro> have:
>>
>> Pedro>  target/resume.h
>> Pedro>  target/waitstatus.[c|h]
>> Pedro>  target/wait.h
>> Pedro>  nat/i386-nat.c
>> Pedro>  nat/linux-nat.c
>> Pedro>  nat/linux-ptrace.c
>> Pedro>  nat/linux-waitpid.c
>> Pedro>  etc.
>>
>> Pedro> Is this what you're thinking of?  _This_, I'm fine with.
>>
>> Yeah, this is what I think we ought to do.
>>

>> Pedro> It's actually very similar to something else I suggested on IRC,
>> Pedro> but forgot to put in email form: "IMO, the interfaces themselves
>> Pedro> would be in an include dir.  e.g.,
>> Pedro> gdb/include/target-waitstatus.h or some such, and then we'd have
>> Pedro> gdb/nat/linux-nat.c, etc."
>>
>> I'm usually against include dirs, but if they are near enough to the
>> implementation it is ok by me.  My issue with them is mainly
>> forgettability -- like, I never, ever remember to look for things in
>> src/include/gdb; and then directories like this tend to become forgotten
>> graveyards.

Agreed.  grep-friendliness is the antithesis of scattering
things around in lots of out of sight subdirs.  But note I was suggesting
a new gdb/include/, not the existing src/include/gdb.  Anyway, let's leave
this idea out for now.

> Yea, we shouldn't put anything in src/include/gdb unless it is
> absolutely necessary.  That pretty much translates into "unless sim
> needs it".

*nod*

-- 
Pedro Alves