Community
Participate
Working Groups
The vast majority of debugger functionality (such as the DSF-GDB debugger integration) is not tied to a particular language such as C/C++. It would therefore be of value that DSF-GDB functionality (and in general, the DSF framework) be available in way that allows IDEs other than CDT to launch and debug native executables (with full IDE integration). Preferably without a dependency on the whole of the CDT IDE, which is what happens currently. See this thread for more info and motivation: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg26771.html
Ok, so, at this stage I don't really care much that most of CDT is pulled as dependency when extending DSF/GDB debugging support. It's not an issue in practice, it would just be a neat thing to have. However, to fully integrate the CDT debugger into a custom language/editor, some CDT UI internal APIs had to be used, and that worries me a bit. It would be good to modify CDT (perhaps exposing some more APIs publicly) so the integration could be done without using internal APIs. For reference, these where the internal APIs used: This whole class is instantiated in the code of custom TabGroup: org.eclipse.cdt.dsf.gdb.internal.ui.launching.LocalApplicationCDebuggerTab These action classes are referred to in the plugin.xml, to add them to a custom editor: org.eclipse.cdt.debug.internal.ui.actions.breakpoints.CBreakpointPropertiesRulerActionDelegate org.eclipse.cdt.debug.internal.ui.actions.breakpoints.CAddBreakpointInteractiveRulerActionDelegate org.eclipse.cdt.debug.internal.ui.actions.AddExpressionEditorActionDelegate org.eclipse.cdt.debug.internal.ui.actions.ResumeAtLineActionDelegate org.eclipse.cdt.debug.internal.ui.actions.MoveToLineActionDelegate Also, related to the actions contributed above, this adapter factory contribution was also added, which uses some more CDT internal API. <factory class="org.eclipse.cdt.debug.internal.ui.actions.RetargettableActionAdapterFactory" adaptableType="com.googlecode.goclipse.editors.GoEditor"> <adapter type="org.eclipse.debug.ui.actions.IRunToLineTarget"/> <adapter type="org.eclipse.cdt.debug.internal.ui.actions.IResumeAtLineTarget"/> <adapter type="org.eclipse.cdt.debug.internal.ui.actions.IMoveToLineTarget"/> </factory>
(In reply to Bruno Medeiros from comment #1) > Ok, so, at this stage I don't really care much that most of CDT is pulled as > dependency when extending DSF/GDB debugging support. It's not an issue in > practice, it would just be a neat thing to have. Can you open a new bug for the below changes then? Those should be easier :) > However, to fully integrate the CDT debugger into a custom language/editor, > some CDT UI internal APIs had to be used, and that worries me a bit. It > would be good to modify CDT (perhaps exposing some more APIs publicly) so > the integration could be done without using internal APIs. Many classes were kept internal because they were not needed by anyone (or at least no one spoke up). If you need to use them, many can be made public. > For reference, > these where the internal APIs used: > > This whole class is instantiated in the code of custom TabGroup: > org.eclipse.cdt.dsf.gdb.internal.ui.launching.LocalApplicationCDebuggerTab There is a new UI planned for launching and much talk about changing lauches altogether. We may not want to make these public just yet, until we have settled on an approach to launching. > These action classes are referred to in the plugin.xml, to add them to a > custom editor: > org.eclipse.cdt.debug.internal.ui.actions.breakpoints. > CBreakpointPropertiesRulerActionDelegate > org.eclipse.cdt.debug.internal.ui.actions.breakpoints. > CAddBreakpointInteractiveRulerActionDelegate > org.eclipse.cdt.debug.internal.ui.actions.AddExpressionEditorActionDelegate > org.eclipse.cdt.debug.internal.ui.actions.ResumeAtLineActionDelegate > org.eclipse.cdt.debug.internal.ui.actions.MoveToLineActionDelegate I didn't look in detail, but those should not be a problem to make public. > Also, related to the actions contributed above, this adapter factory > contribution was also added, which uses some more CDT internal API. > <factory > > class="org.eclipse.cdt.debug.internal.ui.actions. > RetargettableActionAdapterFactory" > adaptableType="com.googlecode.goclipse.editors.GoEditor"> > <adapter type="org.eclipse.debug.ui.actions.IRunToLineTarget"/> > <adapter > type="org.eclipse.cdt.debug.internal.ui.actions.IResumeAtLineTarget"/> > <adapter > type="org.eclipse.cdt.debug.internal.ui.actions.IMoveToLineTarget"/> > </factory> Those above should not be a problem either. I would like to get other people's opinions, but maybe we can keep those internal classes and make them extend the new public classes. That would avoid breaking anyone that uses those internal classes. Patches welcomed.
Created https://bugs.eclipse.org/bugs/show_bug.cgi?id=432323 to its own bug. Should you repost your comment there Marc?
(In reply to Bruno Medeiros from comment #3) > Created https://bugs.eclipse.org/bugs/show_bug.cgi?id=432323 to its own bug. > > Should you repost your comment there Marc? Done. Thanks for opening the new bug.
New Gerrit change created: https://git.eclipse.org/r/60812
