[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] common gdb plugin
|
SWTBot tests where always something we hoped for.
Getting someone to do it is the problem.
Maybe a Google Summer of Code activity for a
student?
Or maybe a company can fund this by hiring a student for a
term?
I have yet to add a plugin, so I wouldn't mind going through the
experience (I'll no doubt need to bug you, though). Architecturally, it really
is odd that we have two sets of plugins targeting the same debugger backend
and they share zero backend implementation code. That said, I'm not looking to
centralize logic that is already duplicated. This new plugin would be a place
for future work. We still have quite a few parity issues to tackle; I'm
confident this new plugin will come in handy. I really dislike copy-n-pasting
code from one plugin into another, but it goes beyond that. There may be
actions/commands/extensions tied to gdb; not having a central plugin in which
to put them in presents a challenge.
Marc has a valid point about the
implications for CDI testing. I would hope that as we work on parity features
or we fix a bug that relies on code in this plugin , we'll test the CDI
feature, even if only manually.
What we really need is a set of SWTBot
based tests that drive the features at a higher level and thus automatically
are applicable to both CDI-GDB and DSF-GDB--not only because it would solve
this problem, but the current low-level testing of DSF-GDB doesn't provide
enough confidence that the features work at the user level.
John
At 08:47 AM 4/7/2010, Doug Schaefer wrote:
Sorry, I got confused with the
terminology. The CDI-GDB layer is actually the debug.mi plug-ins.
At
any rate, I have no objection to a new plug-in. It is work, though, to get
it into the build and all the legal notices in place. We also need to figure
out what feature projects to add it to.
On Wed, Apr 7, 2010 at 9:34
AM, John Cortell <rat042@xxxxxxxxxxxxx> wrote:
- [correction]
- between the CDI-GDB and DSF-GDB plugins. (I'm sure that was obvious,
but just the same).
- At 08:31 AM 4/7/2010, John Cortell wrote:
- I think this is an interesting discussion, but it's tangential to
what I suggested. My suggestion was for a plugin to house
gdb-specific things between the CDI-GDB ajnd CDI-GDB plugin.
- - gdb-isms do not belong in the base cdt debug plugin. I.e., those
plugins should house things common between CDI and DSF but not gdb
specific things
- - the fact that the base cdt debug plugins currently house CDI is
not ideal but that has nothing to do with my suggestion
- John
- At 07:18 AM 4/7/2010, Marc Khouzam wrote:
- Content-Language: en-US
- Content-Type: multipart/alternative;
-
boundary="_000_F7CE05678329534C957159168FA70DEC524447A763EUSAACMS0703e_"
- Sorry for the confusion. There
was no official decision to stop fixing bugs for CDI. I should
not have talked
- about bug fixes, but more of new features. If there will not
be any new features in CDI, then copying the
- code might be a sufficient solution, to allow the copied DSF code
to evolve with new features.
- But then bug fixes would have to be duplicated...
- Tough call. I'm ok with either
one, if someone wants to take the time to move things
around.
- Marc
- From: cdt-dev-bounces@xxxxxxxxxxx
[ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
Of Mikhail Khodjaiants
- Sent: Tuesday, April 06, 2010 9:52 PM
- To: CDT General developers list.
- Subject: Re: [cdt-dev] common gdb plugin
- On 06/04/2010 8:17 PM, Marc Khouzam wrote:
- In fact, if we are still in
agreement that CDI is no longer being evolved, duplicating the
code would
- not be so bad since we would not change the CDI side of it
anymore.
- I realize that in reality, fixes are still applied to CDI
though, so duplicate code is not a great thing.
- Do we believe this trend will slow down? That would be a
way to help make this decision.
- Marc, I probably missed the call when the agreement was
announced. Many companies are still shipping products based on CDI
and it's a big investment for them to switch to DSF/GDB. If we stop
fixing bugs that's not going to force them to switch to DSF. They
will simply copy the source code and will try to fix the problems
themselves.
- I understand you having been in the similar situation before.
You are now the only person who works full time on DSF/GDB and if
Ericsson decide to stop supporting it then what?
- Doug, you can pretend that the CDI is not there, but it is there
:)
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@xxxxxxxxxxx
- https://dev.eclipse.org/mailman/listinfo/cdt-dev
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@xxxxxxxxxxx
- https://dev.eclipse.org/mailman/listinfo/cdt-dev
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@xxxxxxxxxxx
- https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
