If you are developing software for multiple platforms, or distributed software for remote systems (whether using a homogenous or heterogenous collection of machines), you can use the multi-context support provided by Local/Remote C/C++ projects in order to target your projects between multiple machines.
A context is essentially a named association between a directory located on some host, and a collection of data associated with it that the IDE will use when interacting with that context. Typically, each Local/Remote C/C++ project is associated with a context for each machine that you want to target. A context points to the directory on a target machine where the project source files are stored. These contexts can either target remote machines, or your local machine. Using the Local context facilitates developing your application locally, whether while online or disconnected. See Working with remote contexts and Working with local contexts for more information on the differences between working with these different types of contexts.
In order to fully use multi-context support, your project must be a Synchronized project. A synchronized project is a project that has a Local context and one or more remote context with which it is synchronized. Initially upon project creation it has one remote context with which it is synchronized, but you can add additional contexts at any time, via the Remote Contexts view. Selecting your project will show the list of contexts currently associated with your project, and you can use the view to add additional contexts. With a synchronized project, a copy of your files is maintained on the local workstation and on each machine the project is connected to. When you edit a file you are editing the local copy. When you save the file the changes are pushed to one or more of the remote machines (depending on your synchronization settings in the Remote Reconciler view) and the remote copies are updated. If you make a change directly to a remote copy that change will be detected by the Remote Reconciler and it can be synched back to the local copy (if you change both the local and remote copies, conflicts can be merged using a merge tool). Usually only text files are kept in sync, files generated from a build such as object files and executables are kept only on the machine where they were built and are not copied back to the client. The local copy of the files is essentially the master copy. If you become disconnected you can still edit the local copies and when you reconnect the changes will be pushed to the remote copies. Integrated version control systems, such as Rational Team Concert, work with the local copy. Utilizing Offline Mode will disconnect all of your connections and switch all projects to use a Local context to facilitate local development while you are offline.
If your project is not already a synchronized project but you wish to use multi-context support, you can convert it into a synchronized project by selecting "Associate Local Location" from the project's context menu. This will invoke a wizard that will allow you to associate an initial primary context with your project.
When a project has multiple remote contexts, one of them must be the primary context. When you perform actions in the IDE, such as launching a build, the command will be sent to the primary context. You may switch the primary context at any time. The Remote Reconciler only synchronizes with the primary context, but it remembers all the files that have been updated, so when you switch to a new primary context it will automatically push all the changes since the last time that context was set as the primary context. This behavior allows you to be disconnected from the non-primary contexts. You may not want to be connected to all your remote contexts all the time.
When you switch to a context for the first time (i.e. make it your primary context), you will be presented with a wizard that allows you to setup how you wish to interact with that project.

Depending on the hardware and OS platform that the context is targeting, you will be presented with choices as to which compiler toolchain you wish to use in that context for both build and parsing, and also some indexing options. The wizard will properly configure a service configuration for the context in order to tell the IDE to obtain its various services (such as building and indexing) from that machine, and it will also create a build configuration corresponding to the context, so that you can configure your project to build properly for that context, with different environment variables, build commands/build targets, and other various info. As you switch back and forth between your various contexts, the IDE will remember the build and service configurations that you were using at the time when you switched away from a given context to a different context. Later, if you switch back again to that context, those same build and service configurations will be used again, so you will only see the wizard the first time you switch to a new context that you have not previously visited.
While you are working with a given primary context, you can edit, navigate, build, debug, run code coverage tooling, and perform performance analysis of your application. There are some limitations however depending on the hardware and OS of the platform your context is targeting, and some tools may behave differently or be unavailable for certain contexts. See Working with remote contexts and Working with local contexts for more information on the differences between working with these different types of contexts.