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: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: lgustavo at codesourcery dot com, "'gdb-patches\ at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Mon, 05 Aug 2013 13:11:58 -0600
- 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>
>>>>> "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.
Pedro> What else goes in "target/" ? remote.c, corelow.c, etc.?
Yes, I see the issue here; but I think it is far enough off that we
should ignore it. Just merging the bits we can merge today is enough to
occupy our energies.
Pedro> Do we move things into subdirectories beneath it too, for better
Pedro> submodule partitioning? I didn't want to suggest starting a
Pedro> mass move, that's easy to overdo.
Either way is fine by me.
gdb-ish seems to be to prefer flatter.
Pedro> (That was the point at which I
Pedro> suggested that someone thinks this through, and comes up with an
Pedro> initial design/guide of what things will look like in the end, so
Pedro> that we can then discuss and hash it out.)
If reasonably quick I think it is better to come up with a plan now, at
the beginning. It doesn't have to be a perfect plan, but we're already
hitting the limits of the current ("stuff it all in common/") plan.
A little investment now will pay off: we won't curse ourselves in two
years.
Tom