Re: What's with all the Cisco stuff?

[Jim Blandy <jimb@cygnus.com>]

As long as we're talking about philosophy...

I agree very much with Stan that GDB should be a bag of tools that
just works, without getting fussy about exactly which features you
configured in, and which you left out.  I come closest to throwing a
tantrum when I have to struggle with my debugger while debugging
something else, under a deadline.  And I'm on Cygnus's GDB team ---
what's it like for someone else?

However, I am concerned about the approach described here, which I
suspect is really at the heart of JT's concerns:

    Ultimately I'd like to see more modularity for system-specific
    bits, but we're not there yet, and I don't want to see users
    switching to other debuggers because we're waiting for somebody to
    write more elegant code.

I read this as, "We will integrate features people want even if they
are non-modular.  Doing them in a modular way takes too much time.
We'll get around to it eventually."

I don't think this approach is long-term sustainable.  We don't need
modularity because it's beautiful --- we need modularity because,
although we are under deadlines now, we will also be under deadlines a
year from now.  Or two years from now.

Beauty and modularity are different.  GDB's processor architecture
interface (pre multi-arch) is modular, but not beautiful.  We support,
what, twenty different processors?  But clearly, you can work on GDB
without knowing them all.  So that's a successful structuring.

The problem with the Cisco changes is that they're just sort of mixed
in with the remote stuff (among other things), which ought to be
staying really simple.  When I want to understand how remote.c works,
I need to read the Cisco stuff just to reassure myself that it isn't
relevant.  Is everyone prepared to jump into remote.c for a contract,
now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)?

I don't have specific ideas for how to fix this, though.  But I do
think JT's identified a real problem.