[PATCH] Refactor common/target-common into meaningful bits
Pedro Alves
palves@redhat.com
Tue Aug 6 08:48:00 GMT 2013
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
More information about the Gdb-patches
mailing list