PTP/designs/remote

Remote Development Tools Designs

List of Authors:

   Chris Recoskie (recoskie@ca.ibm.com)
   Greg Watson (grw@us.ibm.com)

Background

This page is for low level technical details, notes, and discussions of the Remote Development Tools (RDT) effort. For overall planning, see the Remote Development Tools Planning Page

Presentations

• Remote Indexing & Searches Presented at the CDT Summit 2006 detailing the need for remote indexing.

• Remote Development Presented at the CDT Summit 2007 detailing the motivation behind the need for remote development tools and the status of current efforts.

Architecture Requirements

• Dependencies
  • RDT should not introduce new dependencies for other projects (e.g. CDT should not have to depend on RSE)
• Extensible Framework
  • APIs should not be tied to any specific protocol or service provider. We wish to allow for different protocols to be used, potentially at the same time.
    • E.g., we should not be assuming everything is SSH
    • E.g., we should not be assuming everything is done via RSE.
• Vendor Neutrality
  • APIs and reference implementations should be vendor neutral. We wish to have frameworks and solutions that have value for the entire community.
• Ease of Use
  • User experience for local scenarios should not change in any appreciable way in the presence of remote tools.
  • We should try to hide the remote functionality from the user wherever possible. For the average user, once they have chosen a remote project and setup their connections, it should "just work"
  • The primary use case we are trying to address is users that have the entirety of their project residing on a single remote machine. We should endeavour to make this scenario as simple to configure and use as possible. For example, although it is necessary for the user to setup a connection to the remote machine, they should not be required to set this up for each individual service if all of their services are coming from the same machine via the same connection method.
  • It should be easy to select a sensible configuration of services (perhaps automatically) that make up the user's environment. Choices of certain services should influence the defaults for other services.
  • Configuration of services should be able to be specified for different build configurations.
  • Configuration should be done as much as possible through the New Project Wizard. Users should be prompted at this point to setup required remote connections.

Use Cases

This needs fleshing out into some more detailed documents. Here are some basic use cases:

• Entirely Local
• Local edit with remote build and/or debug
• User is developing for a single remote machine which houses all services (edit, build, debug, etc.
• User is developing for a remote machine but different services reside on different machines (e.g. build on one machine, debug on another).
• User is doing multi-platform development for many different remote machines, each of which houses all services, but depending on what build configuration they are targeting, they wish the services to reside on the corresponding target machine.

General

Replacement for IPath that abstracts around the remote/local nature of paths

Proposal for a service model to govern remote projects: Service Model For Remote Projects

Eclipse File System Support

We are currently looking at refactoring CDT for the 5.0/Ganymede release to add support for the Eclipse File System.

• General EFS notes/designs

The main areas of CDT that need to be tackled are:

• Editor
• CModel( e.g. Outline View)
• Parsing/Indexing
• Analysis Views(Search, Call Hierarchy, Type Hierarchy, etc.)
• Build
• Launch/Debug

Build

There are currently two builders planned:

• Remote Standard Make A remote-enabled version of CDT's Standard Make. Essentially, a make-based builder that uses a remote shell protocol (e.g. SSH) to invoke a builder (e.g. GNU make) on a user-crafted buildfile (makefile). We are planning on tackling this after EFS support, hopefully in time for CDT 5.0, a.k.a. Ganymede.
• Remote Managed Build A remote-enabled version of CDT's Managed Build. In this case the Managed Build System would know about your compile settings, and execute the required build commands directly via the shell protocol (e.g. SSH). Implementation date is currently TBD.

Indexing

It is planned to provide a Remote Indexing Service based along the lines of the prototype developed by IBM.

Launch/Debug

Provide a launch configuration for remote launches. This will be roughly along the same lines as the RSE remote CDT launch configuration. The user should be able to specify the location of the executable (either local or remote) and the host on which the executable will be launched (either local or remote). Issues to consider include:

• May need to copy the executable from the build location to the launch location
• The architecture of the build and launch machines may be different
• Where to get the environment from
• Pre- and post-launch actions (e.g. to move input/output data files)

Provide a launch configuration for remote debugging. Although debugging an executable remotely is supported in CDT (using gdbserver), much of the launch must be performed manually. By extending the debug launch configuration, we will allow the remote services to be used to copy the executable to the remote target, and then invoke the debug server automatically. Issues to consider include:

• The architecture differences between the executable and the debug server
• Using alternate debug servers (other than gdbserver)