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

[Greg Watson <g.watson@xxxxxxxxxxxx>]

On Nov 22, 2011, at 8:02 PM, Corey Ashford wrote:

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

No. I think you're confusing RDT and RSE. RDT provides the remote and synchronized project infrastructure. RSE is just used to provide the communication channel with the target machine RDT can use RSE or it can use other remote providers, such as Remote Tools (part of PTP). The use of RSE is independent of whether a remote indexer is used or not, however remote projects always have to use a remote indexer as the source is always located remotely. There is no way I know of that you could automatically decide to enable/disable remote indexing based on the project location, since this just selects the communications channel (i.e. RSE or Remote Tools), and there may be legitimate reasons for not wanting the indexer to be used if the project location is remote.

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

Synchronized projects allow you to build the same source locally and remotely. This is a very nice feature as it allows the developer to do testing/debugging on their local machine, then switch to the remote version when they are ready to build and deploy on the remote target. However, I agree that in the remote project case, it would make no sense to build locally when the source is located remotely.

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

This is because the CDT "Paths and Symbols" properties page is not extensible enough to support remote projects. 

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

This is easy to say, but I think much more difficult to achieve. CDT's search makes a lot of assumptions about project location, so RDT needs to provide it's own remote search page. There is also no way to determine if a "search service" is "offered by a remote connection". Local searching does not work on a remote project since there is no local index. 

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

That's a shame because synchronized projects provide a much more flexible and powerful project type. I believe most users will choose this model over remote projects as they require little or no configuration and have far fewer problems and limitations. I would have thought synchronized projects would be at least as easy for you to support as remote projects, since they differ very little from a normal CDT project. 

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

I don't think the remote nature precludes you from using any of the standard CDT properties, however some may be hidden to try to make it less confusing to users, since many of the properties have no meaning in the remote context. You'd have to check the plugin.xml in org.eclipse.ptp.rdt.ui to work out exactly what is being done here.

Greg