 |
 |
 |
Thinks locally, executes remotely
The way Remote Programming works is actually very simple. All sources are made available on the desktop machine - either because they’re local files or because they’re located in a shared directory. For standard operations, GPS works as it normally would with a local project but when remote action (compilation, debugging or execution) is required, GPS connects to the remote machine, opens a shell session, synchronizes the local and remote environment when necessary, and performs the action using SSH, RSH, Telnet, or any custom tools via an XML configuration file.
Once connected, the IDE controls the remote shell directly by sending commands and analyzing the responses. The following shells are supported: BASH, SH, TCSH, CSH, and Windows’ shell cmd.exe. This mechanism requires no specific installation on the remote machine.
Full user control
There are 2 major advantages for using a remote session rather than a straight remote execution of the program. First, the user has control over the shell configuration before any execution occurs allowing the full setup of default paths, dependencies, global variables, and so on. Second, the user only connects once to the remote server ensuring that consecutive remote operations are much faster because there is no connection overhead.
Efficient file synchronization
GPS also takes care of file synchronization when necessary. This means that the project’s files either live in shared or local drives. When using a drive shared between the local host and the remote server, no explicit synchronization is required. When project’s files are stored locally, GPS synchronizes the local and remote machines before and after any remote action, ensuring that the correct files are compiled or executed, and that any modified files are retrieved. This synchronization is performed using rsync, well known for its efficiency, minimizing the network traffic for any of these operations.
|
|
|