Maybe when I’m done with build ;).
The true test of DSF will be integrating another compiler that isn’t gdb, or talks MI. At the moment, I’d expect that is prohibitive due to DSF’s complexity and it might be even cheaper to build a new framework for it, assuming the Platform Debug framework
on it’s own isn’t good enough. And we have two on the table, lldb talking it’s lingua franca, and the Windows debug services.
But we’ll leave that aside for now. I just wanted to get people thinking about it so when it does come time to invest, they challenge the assumptions they’re making and do the right thing.
Doug.
Although I have to agree that DSF is complicated, I also would be surprised to see anyone put in the investment to replace it in the near future.
Replacing the build system has been discussed for years and years before it may finally happen. And it probably wouldn't happen at all without Doug's efforts.
On the debug side, DSF/DSF-GDB is actively being worked on and continues to evolve, with plans to support very large multi-core debugging configurations.
The GDB integration is far richer than the original 'example' it was meant to be, and provides more value to extenders than DSF on its own.
I don't expect replacing it to be an easy endeavour and certainly not as a project for someone's spare time.
So, in practice, although there is some magic, that magic works and allows us to have a rich debugger experience that continues to improve.
And I believe it has a track record of being a worthwhile investment, especially combined with GDB.
Marc
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?
|