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 _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
