Hi Doug, Greg –
You might consider using the TCF Target Explorer as a generic container / API to unify the various target management systems that CDT / PTP may want to support.
We recently added a toolbar dropdown to TCF Target Explorer, for creating new target connections, choosing a “current target connection”, connecting and performing
operations.
This is what it looks like when you install “TCF Target Explorer” from Luna Simrel into the Luna C/C++ Package – it seems nicely aligned with the toolbar
you have in mind:
![](jpgROfaU4xYcn.jpg)
Right now, the only type of connections supported in Open Source are TCF connections. But we’ve already extended this for our commercial product to provide
different connection types. Since target explorer is very generic and agnostic, it should be possible to implement a bridge for RSE type of connections, or JSch type of connections for PTP.
We don’t currently have support for matching the architecture of targets against the architecture of projects. But any target connection (“peer” in terms
of TCF/TE) has generic attributes. Using the IPropertiesAccessService, these are easily obtained.
In terms of the code, TCF/TE follows a modern service-oriented architecture. Here is some sample code to obtain the currently selected default connection,
and then query some properties like IP Address and port. Note how – thanks to the service architecture – different service implementations are possible for a “UI Driven Eclipse” versus a different configuration that might get the IDefaultContextService from
a non-UI application.
1.
Use the IDefaultContextService to get the currently active connection.
IDefaultContextService
svc = ServiceManager.getInstance().getService(IDefaultContextService.class);
IPeerNode
ctx =
svc.getDefaultContext(null);
2.
Use the IPropertiesAccessService to get the IP address and port of the currently active connection.
IPropertiesAccessService
service = ServiceManager.getInstance().getService(newLocatorNode.getPeer(),
IPropertiesAccessService.class);
Map<String,String>
attrs =
service.getTargetAddress(newLocatorNode.getPeer());
String
peerHost =
attrs.get(IPropertiesAccessServiceConstants.PROP_ADDRESS);
String
peerPort =
attrs.get(IPropertiesAccessServiceConstants.PROP_PORT);
Similar Services and constants exist for FileTransfer and Terminals service – see here for the generic (non-TCF) services:
http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/target_explorer/plugins/org.eclipse.tcf.te.runtime.services/src/org/eclipse/tcf/te/runtime/services/interfaces?h=1.2_luna
And here for some basic core TCF services which I referenced above:
http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/target_explorer/plugins/org.eclipse.tcf.te.tcf.locator/src/org/eclipse/tcf/te/tcf/locator/interfaces/services?h=1.2_luna
As you see, the dropdown and locator (target address) API’s are currently in the non-agnostic i.e. TCF-specific part.
We could potentially consider pushing down some of this into the agnostic (non-TCF) part if you are interested.
HTH, let us know what you think.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
Cool. Thanks Greg. That's another great example we need to make sure works.
Right now, the middle selector assumes one launch configuration per entry. That means only one launch configuration type. Remote launches
tend to have their own launch configuration types. This means the user would have to create additional launch configurations manually and select those types.
But the UX I want to achieve for CDT-based projects is that there's one launch configuration entry per executable project. And it
needs to be able to handle all the types of remote launches and the local launch.
I'm not sure how to get there. We could make the middle selector map to more than one launch configuration and the correct one that
runs is based on the active target. That messes up the API pretty bad and we have a lot of assumptions around that it's a one-to-one mapping.
From:
cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Greg Watson [g.watson@xxxxxxxxxxxx]
Sent: Wednesday, July 02, 2014 3:22 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Targets in the LaunchBar
Doug,
PTP has it’s own target management system, so it would be nice to use this with the new LaunchBar. It would be difficult to do this if CDT provided a target system that everyone had to
use.
We could also provide a remote launch target in the remote services plugins (org.eclipse.remote.*) which multiplex across different remote implementations (RSE and JSch). That way there
would need to be one remote launcher.
Hey gang, I'm struggling with how to model targets in the LaunchBar. (As a reminder of what the LaunchBar looks like, see here: http://cdtdoug.ca/wp-content/uploads/2014/03/Screen-Shot-2014-03-14-at-10.08.11-AM.png)
By default, there is a target called Local Machine. There's no semantics to that target, and it really means do whatever the launch
configuration naturally does, which more often than not is to launch the application on the local machine.
For Momentics, targets are the QNX-y things we launch on. We have our own target management system which predates everything you see
at Eclipse, so we've stuck with it. We have a target registry that maintains the list of targets and we produce that for the LaunchBar. But I don't think it would be wise to force everyone to use our target management system.
As I have it now in the CDT, targets are very simple things that only have an id and a name. The launch config descriptors provide
a list of valid targets they can launch on. The default launch config descriptor simply returns an object for the local machine. The idea is that the descriptors know what it means to launch on a target so they can deal with changes in active target and feeding
it to the launch delegates however they like. So it can be whatever target system makes sense.
The problem is what do we do with the CDT itself. We've never really modelled launching on targets. We do have the remote launch that
uses the RSE. But there's no semantics that link it to a project. This could be done by adding a nature to the project to enable remote launches. Or it could be done by marking toolchains as cross toolchains so we can figure out what targets their build artifacts
can run on. We have the cross toolchain, but it's woefully inadequate for this since it doesn't keep track of the real target platforms (os, arch).
Has anyone given this any thought or is everyone happy using their own target management system? How would we use TCF in place of
RSE? Or do we want to go through the effort to support remote launching in the CDT proper at all?
Look forward to your thoughts,
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev