[
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 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.
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.
What do you think? Am I ignoring some important use cases?
- Corey
