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

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 11/21/2011 01:56 PM, Greg Watson wrote:
> 
> On Nov 21, 2011, at 4:15 PM, Corey Ashford wrote:
> 
>> 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.
> 
> You can certainly do this, but a) the local indexer will think that the files are local, but since they are actually remote, this will result in a huge performance hit; and b) the build will happen locally and will also take a performance hit, since every file will need to be copied to the local machine, and you'll also end up with a binary for the wrong architecture on the wrong machine. Some parts of Eclipse are also still not EFS aware (e.g. Team support) so there would be a risk that someone might use this and things would blow up badly.
>

There could be smarts placed into the CDT so that depending on the type
of remote connection, it defaults to running the indexing remotely or
locally, but you could make it switchable.  For example if the project
uses RDT for specifying the base directory, the project could default to
remote indexing and always use remote builds.  The user could specify
local indexing if they want (though I don't know why they would, given
the performance hit).

If it uses RSE, there is no remote indexer (right?), so you could fix it
use only local indexing, but always build remotely.

I don't think it ever makes sense to build locally on remote filesystems
(unless you are talking about synchronized projects utilizing cross
compilers).

> Remote projects run a remote indexer to overcome the problems in (a) and use a remote builder for (b). They have limitations however, since the remote indexer will never provide all the functionality that the local indexer provides, and it only works for C/C++ (thus excluding remote projects for Fortran, Python, and any other language).
> 
> The alternative, synchronized project, provides a kind of half-way-house that over comes many of these problems, including the Team support issue. The files are kept both locally and remotely, so the local indexer can run at full speed. Builds are still handled by a remote builder so that you get the executable on the correct machine. They have a few other advantages also.
> 
>>
>> 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.
> 
> Actually there are three types: local, remote, and synchronized. It would probably be possible to do without the synchronized nature, but I think it would be much more difficult for remote projects to do without the remote nature since they use the nature for a bunch of additional properties page,include browsing, the C model, searching, and other stuff too I think.

In the RDT it has seemed unintuitive to me that there's a separate
project properties section for "Remote Paths and Symbols", in addition
to the "Paths and Symbols" under C/C++ General.  I would hope that this
changes sometime soon to be integrated into a single section.

Searching could have the same smarts about search services that would be
offered by the remote connection.  If the remote connection doesn't
provide remote search, then only allow local searching.

Synchronized projects would seem to require a different project nature.
 I don't see a way around that one, and I do think we'd like to be able
to support synchronized projects with Linux Tools.

Can you briefly explain why adding a new nature to a project precludes
you from directly using the CDT's various systems for project wizards,
compiler properties, etc.?  As I understand it, project natures can be
(but don't have to be) "additive", and allow the addition of new
functionality, rather than removing compatibility with the other natures.

- Corey