Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

Perhaps we should pick up this discussion in a couple of weeks once we have both had time to review where we are now.

On 24 May 2016 at 18:47, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:
>> On 24 May 2016, at 19:26, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>> In this case there are no classes removed from CDT 9 that affect arm plug-ins.
> I don't understand this, as long as installing the plug-ins fails with missing dependencies, those classes are gone.
Of course you are correct! The CDI MI plug-ins are gone, along with their classes.

However while your existing code has a dependency on them, it does not actually use them. For example in TabDebugger it sets IMILaunchConfigurationConstants.ATTR_DEBUGGER_COMMAND_FACTORY. But since DSF does not use the CDI command factory there was never a need to reference IMILaunchConfigurationConstants (the now deleted class) or have a dependency on org.eclipse.cdt.debug.mi.core plug-in.

The change in the launch configuration delegate dealt with a serious race condition where the wrong thing was being passed around all over the place (launch configurations instead of launches). 

>> API changes to existing classes
>> were made.
> I need to study the changes more thoroughly, but generally I think that significant API changes should be done by adding new classes and leaving the old functionality there, not by removing old functionality.

In an ideal world yes. That was the situation that CDT was in for 5 years since the release of CDT 8.0. However, unfortunately some of the API in 8.0 and before was simply wrong. We are in a situation that we needed to break API compatibility to fix some serious issues. 

> the GNU ARM debugging plug-ins are full of unorthodox patches, some requiring copying entire classes locally because they were too rigid and did not allow to be customised.
I believe every extension of DSF has at least some in that situation, so while not ideal, it is actually allowed. Some of the API changes have been done specifically to ameliorate the places where it is harder than it should be to extend DSF. 

> initially I thought that starting a GDB server before the GDB client shouldn't be a big deal, but the design of DSF (or my poor understanding of it) made things very difficult.
I am very pleased that you managed to solve these problems. I hope that some of these improvements you have identified can be fed back into CDT.

> the next challenge was to accommodate different startup sequences, and, again, implementation was quite nightmarish.
> I did not check the latest versions, but if you want to support different debuggers (like lldb) and different/custom startup custom sequences, there is lot of work required for DSF.

Yes there is!

>> Interestingly you, as the GNU Arm Eclipse maintainer, are in the same
>> situation as the core CDT project.
> there is a small difference, however: all the GNU ARM Eclipse development efforts were funded by my private resources, which are not unlimited.
As is all the support I am providing to you now ;-)

> regards,
> Liviu
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top