This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Refactor common/target-common into meaningful bits
- From: Pedro Alves <palves at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: tromey at redhat dot com, lgustavo at codesourcery dot com, gdb-patches at sourceware dot org
- Date: Tue, 06 Aug 2013 09:48:08 +0100
- Subject: Re: [PATCH] Refactor common/target-common into meaningful bits
- References: <51FA9649 dot 5060008 at codesourcery dot com> <87vc3pfghs dot fsf at fleche dot redhat dot com> <51FAA061 dot 4050005 at codesourcery dot com> <51FB7BFB dot 90100 at redhat dot com> <87txj7byz7 dot fsf at fleche dot redhat dot com> <51FF81E6 dot 7050006 at redhat dot com> <87bo5c7y0x dot fsf at fleche dot redhat dot com> <201308051920 dot r75JKhN7009020 at glazunov dot sibelius dot xs4all dot nl>
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