Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

[Liviu Ionescu <ilg@xxxxxxxxxx>]

> On 24 May 2016, at 19:45, Derek Morris <dmsubs@xxxxxxxxxxxxx> wrote:
> 
> Would it not be possible for you (Liviu) to abstract the interfaces you require and provide two different implementations - one for Neon and the other for pre-Neon? Yes, a little bit of work is abstracting the interfaces and to implement it twice, and another to work out which one to install, but this should then enable you to support all versions.

this seems to require some significant effort.

if a simple attempt to remove the dependencies from those classes will fail, I'll simply bring them in the project.

when support for 8.x will no longer be needed (probably not sooner than 2 years from now), if we'll still be alive and kicking, we'll remove them.

if there are clever tricks allowing to provide different versions of plugins in the same p2 repository, and make the clients automatically choose which to install, I'm ready to consider them, but maintaining different update repositories is too expensive for me.

> 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.

> 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.

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.

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.

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.

> 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.


regards,

Liviu