Remote Development Tools Designs
List of Authors:
Chris Recoskie (email@example.com) Greg Watson (firstname.lastname@example.org)
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 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.
- No new dependencies for other projects (e.g. CDT should not have to depend on RSE)
- User experience for local scenarios should not change in any appreciable way.
- Try to hide the remote functionality from the user wherever possible. Once the user has chosen a remote project and setup their connections it should "just work"
- 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.
- APIs and reference implementations should be vendor neutral.
- Ease of Use
- 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.
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.
Proposal for a service model to govern remote projects: Service Model For Remote Projects
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:
- CModel( e.g. Outline View)
- Analysis Views(Search, Call Hierarchy, Type Hierarchy, etc.)
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...