Re: [linuxtools-dev] PTP/RDT and remote linuxtools

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 10/11/2011 03:00 PM, Jeff Johnston wrote:
> 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.

OK, so that means locking the launchers into the connection that's being
used for the project.  I think that's the easiest-to-use route, for sure.

> 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.

That seems reasonable; thanks for your thoughts.

I will have a closer look at your latest RDT branch.  It sounds quite
promising!

Regards,

- Corey