|
Note: I wasn't talking about refactoring DSF or DSF-GDB themselves, but rather refactor CDT Core and UI to pick out utils and other common code into separate plugins. Ideally this would be a superficial refactoring - just moving a few classes around, maybe
a few methods - but in practice I reckon it wouldn't be that simple, there be more in-depth refactoring required. (I haven't looked into it in detail) I might give it a go if I have the time.
OK, I’d like to se a list of such refactorings first before I can provide my thoughts on it. I’m actually surprised there would be anything like that. The native’s, like the Spawner, have already been refactored out into a separate build.
As for refactoring DSF itself, I agree with Mark, things are actually pretty decent at the moment. Even if DSF doesn't work very well for implementing a new debugger integration (that isn't GDB nor MI-based), at least it still gives us DSF-GDB, which is quite
nice.
Sure, there are a few things I'd like to see in DSF-GDB that make the handling of non-C/C++ languages better. But if I look at the big picture, it's actually in GDB itself that a lot of limitations come from, so that is a stress point much more than DSF-GDB
is...
Agreed. And this is where the investment in CDT’s GDB integration is taking place and where I’d expect any changes you need could be done. And this is the driver behind the original topic of this message, deprecating CDI.
This does pose an interesting question: if someone where to write say, native LLDB integration for CDT, would they be better off using DSF as a base, or writing a debugger integration from scratch (just Platform Debug)...
It does.
|
