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