[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] PTP/RDT and remote linuxtools
|
On 10/11/2011 05:03 PM, Corey Ashford wrote:
On 10/11/2011 12:48 PM, Jeff Johnston wrote:
On 09/07/2011 05:21 PM, Jeff Johnston wrote:
Hi Wainer,
No estimated date on the prototype. I have it currently in a private git
branch. I have done the first part which was to indirectly reference
files and launching via a proxy. I still need to create the extension
and plug-in part so that RDT can be connected optionally.
Just to let people know that I have updated the RDT branch with the
extension and plug-in necessary to allow RDT to be optionally connected
with Autotools.
The extension lists the nature id it supports so in theory, we could
support alternates to RDT some day if desired.
The shared code checks the project nature and at the moment just looks
for the RDT remote nature. If not found, it uses local proxies for file
access, launching, and the platform OS. If the RDT nature is found, it
looks for the extension that supports the RDT nature and then gets a
factory which returns the proxies for file access, launching, and
retrieving the platform OS (needed in the case of Windows support).
I'd appreciate any comments folks have on this branch.
I tend to like it because RDT is optional. We are free to support other
forms or multiple forms of remote project strategy if desired.
This sounds like a good idea, to base it off of the project nature.
PTP "Synchronized Projects" use a different project nature than the
remote projects: org.eclipse.ptp.rdt.sync.core.remoteSyncNature.
However, we should be able to use RDT for running autoconf, launching
executables, profilers, debuggers, etc. on synchronized projects too.
Thanks for the heads up. I'll add a 2nd extension use to the RDT
plug-in and use the same classes to service the synchronized projects.
I'll add the additional nature to check in the main proxy manager as well.
As for launchers, how would you handle which connection type to choose?
There is the case of wanting to develop using, say RDT, and then launch
using RSE on a different machine. This sounds kind of ugly, and perhaps
we should not support this use case yet. If we limit the user to
executing (debugging, profiling, etc.) on the same machine as where the
executable is built, the launcher can just look in the project (where
the executable is located) for the connection information.
My thoughts are that we don't support using the remote launcher on RDT
projects (at least not for now). So, we end up supporting local and RDT
projects executing where the project resides and allow launching a local
executable on a compatible remote system using the special remote
launcher (as we do today for remote Valgrind support).
If future users really want the RDT project executing on a compatible
system to be supported, I guess we could consider caching files locally
using the proxy and then shuttle them over via the normal remote
mechanisms provided by the UI. I don't think many people are going to
ask for this. I imagine users that are comfortable enough to use RDT to
set up a project would simply synchronize the project to another system
or create a new RDT project on the additional system.
What do you think? Am I ignoring some important use cases?
- Corey
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
