TM used to be +2 because of consuming internal non-API
When the remoteCDT plugin is in CDT, then TM can go +1
I believe that CDT can remain at +1 because the reverse
dependency (remoteCDT --> RSE) only consumes public API which is not subject
So we should be able to build at the same
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Hmm.... Yeah... then CDT would have to go from a +1 Galileo project to a
+3? Unless TM decided to move up to +1?
Sounds messy, at least for
IBM CDT and RDT
03/04/2009 04:05 PM
Please respond to
Management developer discussions
I like the idea of having the RSE-based remote launch in CDT, but it
would introduce a dependency from CDT on the Target Management project, which
would have implications on the CDT build.
As some of you may know, one part of the TM / RSE offering is a
"Remote CDT" Launch configuration, which allows
The implementation of this feature requires using CDT internal non-API  in order to get the debugger configuration page into the
launch config UI, which is forbidden in Galileo.
- Uploading files through RSE-provided
- Launching the program remotely through an
- Debugging remotely through a remote gdbserver
instance (requires local cross-gdb).
We'd therefore think it makes sense to
move the feature into the CDT
 -- on the RSE side, only public API is
being used. In other words, we propose adding a new optional CDT feature
"Remote Launch" which depends on the RSE, and removing that feature from
the RSE offering.
feature itself doesn't expose any API (everything is "internal"), so
renaming the plugin and/or the package should not be an issue if that is
Does the CDT
Community agree that this is a good thing to do?
Who is the right person to get in touch with for making it
Is it realistic to get that done for
Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member