[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Preventing Eclipse/CDT from offering to debug embedded code locally
|
Hi.
On 07/03/2011 12:46 AM, Marc Khouzam wrote:
About the dialog, I haven't looked much into it but you may find some answers in: CApplicationLaunchShortcut.java
I read through code responsible for that. It's not a part of CDT (its
org.eclipse.debug.internal.ui.contextlaunching.ContextRunner). The
problem is that it looks for any launch shortcuts that could be used to
launch the selection and if it finds more then one it presents that
dialog. As CDT (naturally) registers shortcut to be able to run any
CProject and as my project is also CProject (with additional nature)
this shortcut is also offered to launch embedded code.
I think that maybe CDT projects would need some kind of target
CPU/system notion, and then default shortcut could be set to launch only
host system code.
Or maybe I'm just missing something and there is other easy way to do this.
About the GDBJtagDSFFinalLaunchSequence look at bug 324101 https://bugs.eclipse.org/bugs/show_bug.cgi?id=324101
where I posted a patch. I don't have the setup to test it so I couldn't commit it. If you (or someone else) can test it,
I can commit it,, with whatever modification is necessary.
Great. I wasn't aware this already exists. As I'm not familiar with
Eclipse development process: Do you want me/someone only to test this
patch as good as we can and compare results with current launch sequence
or are some kind of formal test cases required as prerequisite to commit
the patch?
Regards.
Branko
Regards,
Marc
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Branko Drevenšek [branko.drevensek@xxxxxxxxx]
Sent: June 30, 2011 5:11 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Preventing Eclipse/CDT from offering to debug embedded code locally
Hi.
I'm integrating our gcc based toolchain with Eclipse/CDT.
One thing that bothers me and will probably confuse users is the fact,
that when user tries to run embedded application for the first time by
clicking on run or debug icons, Eclipse asks whether to debug
application as "Local C/C++ application" or "'our' embedded application"
(as defined in launch shortcut).
Application will certainly not run as local c/c++ application using
system default gdb... Is there an easy way to prevent this dialog from
popping up? I've read through code that does this and it mostly checks
for project natures, and since we keep C/C++ nature and add our own...
TargetPlatform element has osList&archList fields which are supposed to
do something, but anything I put there makes no difference (didn't
really expect it to, since our launcher doesn't tell, it can launch
that). We use DSF launch derived from cdt.debug.gdbjtag.
---
Now on that. I have another question.
In there, there is GDBJtagDSFFinalLaunchSequence class. It's based on
cdt.dsf.gdb.launching.FinalLaunchSequence, which has recently been
modified to extend ReflectionSequence to allow easier extension. As
GDBJtagDSFFinalLaunchSequence extends "simple" Sequence, i had to copy
most of it's code to adapt it to our requirements. I would expect that
GDBJtagDSFFinalLaunchSequence would be extended more often than
FinalLaunchSequence.
As far as I understand it, to contribute to CDT one has to raise a bug
and provide a patch, which basically needs to be less than 250 LOC. I
would do this (GDBJtagDSFFinalLaunchSequence based on
ReflectionSequence), but I guess refactoring whole thing to extend
ReflectionSequence would create larger patch. Is there anything I can to
about it?
Thanks in advance.
Branko
_______________________________________________
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
