Skip to main content
Jump to: navigation, search


< PTP‎ | designs
Revision as of 16:33, 11 October 2007 by (Talk | contribs) (Architecture Requirements)

Remote Development Tools Designs

List of Authors:

   Chris Recoskie (
   Greg Watson (


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


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


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

EFS Support

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

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


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.


  • Coming soon...

Back to the top