Moving GDB support out of CDT

[Øyvind Harboe]

How about removing GDB support from CDT?

Some loose thoughs on this subject....


GDB as a part of CDT isn't exactly moving along at breakneck speed.

It has too few committers and too few patch contributers. I've tried to
work a bit on a few patches and given how slowly things move along,
I can see why this is discouraging to others. Most of my modifications
to CDT have of course been rather handwavy stuff rather than complete
and palatable patches, but a few of the crisper onces were accepted.

Perhaps this is a time to try to think about a new way of doing things?

Possible advantages(mixing different issues a bit here):

- I'm thinking that the GDB CDT code would live on as a library that plugins
could use, preferably different versions could live side-by-side
inside the plugins
- This could open up for more committers as Eclipse/CDT has a very
stringent process for accepting committers. sourceforget cdt-contrib?
- Those that provide the plugins that use the GDB code would decide
which version of the GDB MI code to use, allowing the release
cycle to be indepdenent of CDT/Eclipse
- Yearly release cycles is just too long for something like GDB MI
that still needs a lot of work

Of course this does not actually require any endorsement by Eclipse + CDT
as such, this is open source :-) but it would be good to have some sort
of consensus on how to move ahead.

Some steps that I imagine:

- copy code to cdt-contrib. Rename packages to avoid clashes with
"official" or "legacy" GDB MI code.
- make the GDB MI code library code where different versions can
live side-by-side inside plugins. The idea is that plugin providers
can ship with the CVS HEAD version of the GDB MI library code
- this gives the plugin providers incentive to work on CVS HEAD for
GDB MI library code
- open up for more committers