[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Going to 3.0 for org.eclipse.cdt.dsf.gdb
|
+1
for me. I always prefer to avoid the xyz2 pattern if
possible.
Randy
Hi,
I would like to move the plugin org.eclipse.cdt.dsf.gdb
from 2.0 to 3.0.
The reason is that to fix Bug 249165 (Resume at
line) and Bug 249162 (Move at line), I need to add
methods
to the DSF-GDB runControl service, which requires
adding methods to the interface IMIRunControl
interface.
Since this interface is part of dsf.gdb only and not
DSF, I don't think it is being used outside DSF-GDB.
So, instead of getting into the whole IMIRunControl2
pattern, I'd rather just make change directly.
Anyone thinks is a bad idea?
P.S. I would also remove Deprecated interface in the
same effort
Every plug-in has their own version. There's nothing wrong with
that. And with that the decision on when to change major version also resides
with the plug-in and the people working on it.
We've made a general
decision to allow API changes for CDT 7 if you really need to and communicate
those changes to the community.
Doug.
On Mon, Feb 8, 2010 at 11:44 AM, Marc Khouzam
<marc.khouzam@xxxxxxxxxxxx>
wrote:
It just
hit me that although CDT is going to 7.0, DSF and DSF/GDB have their own
versions and are moving
from 2.0
to 2.1. This prevents me from removing deprecated
interfaces.
Should
we align DSF/DSF-GDB with the CDT versioning decision?
Or maybe
not DSF, but maybe the two DSF-GDB plugins?
Thanks
for any input
Marc
Hi,
In 7.0 I've moved the IReverse* interfaces for the differen reverse
debugging commands from dsf.gdb to debug.core.
The old interfaces are marked as deprecated, but I would like to
remove them.
They are:
org.eclipse.cdt.dsf.gdb.actions.IReverseStepOverHandler
org.eclipse.cdt.dsf.gdb.actions.IReverseStepIntoHandler
org.eclipse.cdt.dsf.gdb.actions.IReverseResumeHandler
org.eclipse.cdt.dsf.gdb.actions.IReverseToggleHandler
org.eclipse.cdt.dsf.gdb.actions.IUncallHandler
Anyone objects or feels it is better to leave them?
Thanks
Marc
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
