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

[Tom Tromey <tromey@redhat.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