You need to be careful about what part of DSF you want to refactor. The original intent was that the general framework could be pushed down to the Platform Debug. That could still be possible with some refactoring I assume.
For the more general gdb/C++ debugging case, we should consider ways to improve the debug experience by leveraging the knowledge that the CDT core has about the code in the projects and about what toolchain is being used to build those projects, which
generally determine which debugger you want to use with DSF.
But I’ll say this, I’m not sure DSF is the right framework for debugger integration to begin with. It does more, like handle the flexible hierarchy, and CDI can’t do that. But there’s way too much magic behind DSF, to quote Uncle Bob ( http://blog.cleancoder.com/uncle-bob/2015/08/06/LetTheMagicDie.html).
We really need to ask ourselves if we really need all that magic.
As I have great success redoing the build system to a simpler model, I imagine we could do the same with debug at some point. And while doing that, we need to make sure we can handle many different languages, not just C and C++ but all the ones that Bruno
works with and the entire Clang and gcc family as well.
Doug.
If someone is willing to do the necessary changes to remove those dependencies, then yes, CDT 9.0 is the ideal opportunity.
Marc
While we're on the subject, any chance to improve the plugin dependencies that the CDT DSF debugger has on the Core and UI CDT plugins? (that is, remove them to only the minimum required - likely requiring refactoring to a CDT commons plugin)
This is a throwback to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=421166 . It might also help make the Standalone debugger a bit leaner?
|