KDevelop/RemoteDevelopment

Definition

"Remote development": development of software where the program used to do the editing of the code and the controlling the build/deployment is running on a different computer system than the one where one or all steps of configure/build/install&deploy/run are done.

Motivation

Being able to build (and/or deploy) on machines other than the one where one runs KDevelop on (e.g. one's laptop). Ranging from real remote machines on the other side of the planet to virtual local ones (VirtualBox & Co). Or just building as another user on one's machine, so one's normal user account's files are protected from some build tool/script going crazy on the home directory accidentally.

Some reasons for doing remote development

other machine is more powerful (or even a supercomputer)
machine has custom setup
special build tools only available on that machine
protection of local system from buggy installation/deployment
saves energy/disk/memory of one's laptop, no noise by fan (if real remote)

Initial Plans

Keep assumption that the complete sources are accessible via the local file system and shared with the remote systems where the build should happen by the usual ways (mounted remote/network filesystem or shared directories with virtual machine). So any editing of the sources should not be touched in this work.

Marching plan:

Collect user stories to gain idea of problem space: which different "build" actions (configure/build/install&deploy/test/run/debug/?), which target systems, which communication/channels to them.
Collect previous/existing attempts/approaches to learn more about solution space
magic happens
Profit!

User stories

IDE on Linux, tools and target on FreeBSD

Code only compiles on a FreeBSD system but system with IDE runs Linux (laptop).
FreeBSD is run in VM, source code directories are mounted using NFS/SSHFS.
Code completion: needed to know right clang flags (-fno-stdinc to avoid the Linux headers, -target=mips64-unkown-freebsd for the right built-in defines) and added include paths for the FreeBSD headers -> works almost perfectly.
Code parsing: works okay speed wise because the NFS is a local connection.
Compilation: very slow because run in the local VM. plans to change to dedicated powerful build serve
Wanted: mapping of remote source path to a local one so that the right file can be opened when double-clicking on the error.
Wanted: improved UI for adding extra clang flags, confusing ATM (needs info: that is for faking parsing of remote compiler by local parser?)

Challenges

need to replicate the complete (build) environment, e.g. all used remote system headers need to be known
proposal: best bet is to properly integrate bundling systems where the platform is more defined than on a remote device. Will also give better semantics on what deploying means that could be used for proper integration in the GUI (needs info: what means "more defined"? what is a "bundling system" here, compared to "remote device"? what "better semantics"?)

Shell integration scope

Wanted: remote build logs parsed and offer same features like for local builds, e.g. linking from error to location in source code (click on error -> cursor in sources). Would be nice to have build process output in KDevelop in real-time (same also wanted for local building with build systems that cannot easily be integrated into KDevelop). A possible implementation would allow a call "make | parse!", where "parse!" would be a KDevelop shell utility that pipes all the output into KDevelop which then tries to do something useful with it, like highlighting errors and making them browsable etc. For the start it might be sufficient if the final build log could by processed by calling "parse! filename", which would be very similar to "open! filename", and very easy to implement. Alternative possible implementation would monitor all output of the attached sessions even without the "parse!" command and would recognize the running tool. E.g. when gdb is used manually, it would directly jump to the specific source locations etc., though this might be quite difficult to achieve (perhaps by hacking Konsole directly).
Wanted: option to attach the integrated debugger. Possible implementation done locally, should somehow pipe the GDB control interface between KDevelop and the debugger instance.

Existing solutions of other products

Initial link dump:

Available technical features

connection to remote machine with "ssh!" command

There is support for connecting to a remote machine through an ssh tunnel, by using the "ssh!" command. Needs on the target machine kdevplatform_shell_environment.sh script, the kdev_dbus_socket_transformer tool and qdbus utility (all in the path). This enables remote system to talk to local KDevelop instance. Example: if you're on a networked file system where files are mounted in the same location, then the "o!" command will open the file on your local machine, otherwise it will try to use fish (not yet available is mapping between different mount points local/remote).