On 10/17/2011 05:52 AM, Greg Watson wrote: >> It's not clear to me why the PTP/RDT developers chose to use a separate >> project type "Remote C/C++ project" and introducing a different mechanism >> for choosing toolchains, instead of reusing the C/C++ project type. Maybe >> Greg Watson can fill us in here... > > With the current CDT design, the only wa to configure the remote aspects of > the project, as well as add a remote nature to the project, is by adding a > new project type. Since toolchains are linked to the project type, this means > that remote version of the toolchains are also required. [...]
Hi Greg, Sorry for the delay in response to your reply. We had a discussion of remote projects on a Linux Tools call today, and this subject came up again. It's not clear to me why Remote C/C++ projects need a remote nature. We can create an RSE- or TM/TCF-based project using the standard CDT C/C++ project wizard, simply by unchecking the "use default location" button, then pulling down the filesystem selector and selecting RSE (for example) and then select a connection and a directory. Instead of using a nature to add remote capability, the tools should be made so that they are location-agnostic (to use Jeff Johnston's great term). I understand this could be a lot of work to get it working correctly, but having two separate lines project types also seems like it could be a maintenance nightmare in the long run, and certainly doesn't make it any easier for end users having two project types to choose from. I'm probably missing some very large issues here that are specific to PTP, so any light that you could shed here would be appreciated. Thanks for your consideration, - Corey _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
