RFC: support for building on remote/virtual/etc machines

[Alexander Richardson]

On 12 September 2016 at 17:37, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Hi,
>
> first of all: congrats for the 5.0 release of my favourite IDE, dear
> maintainers :) So happy KDevelop exists and keeps improving.
>
> Now, there is one issue that bugs me for years, so I want to try to get
> serious with it myself over the following months:
> being able to build (and/or deploy) on machines other than the one where I run
> KDevelop on (e.g. my 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 my machine,
> so my normal user account's files are protected from some build tool/script
> going crazy on the home directory accidentally.
>
> So some reasons for doing remote builds:
> * 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 my laptop, no noise by fan (if real remote)
>
> Looking at current KDevelop (from master to be sure), I found some support for
> remote systems in the Launch Configurations, incl. Remote debugging. So for
> the last part of configure/build/install&deploy/run the concept of non-local
> systems exists as a start. I want to work on extending this to the complete
> set of build actions over the next months.
>
> For this work I would keep the assumption of KDevelop that the complete
> sources are accessible via the local filesystem 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.
>
> But any of the steps build/install(&deploy)/run/debug, they all in the end
> should be configurable to be done on other, remote/virtual systems.
>
> Would you welcome such work? Who else would like to work on this with me? Has
> there been some discussion on this already, any links to notes/threads? Any
> previous attempts?
>
> First step would be collecting use-cases, for developing an abstract idea/
> model of the different "build" actions (configure/build/install&deploy/test/
> run/debug/?), the different target systems and the different communication/
> control channels to them.
> What naming pattern would you like below https://community.kde.org/KDevelop
> where I would like to do some wiki pages for organizing this work?
>
> Cheers
> Friedrich

Hi Friedrich,

I would also very much like to see better support for remote building
in KDevelop but I'm not sure what the best solution is.
I currently need to build code remotely because it only compiles on a
FreeBSD system but I have Linux running on my laptop.
My current solution is to have a VM and mount the sources using NFS/SSHFS.
After figuring out the right clang flags (-fno-stdinc to avoid the
Linux headers, -target=mips64-unkown-freebsd for the right builtin
defines and added include paths for the FreeBSD headers) this gives me
code completion that works almost perfectly.
Code parsing works okay speed wise because the NFS is a local
connection but the compilation is very slow because I'm running it in
the VM. I will probably change this setup to using a dedicated
powerful build server instead of a local VM soon.

It would be very nice to have some kind of build integration that maps
the remote path to a local one so that the right file can be opened
when double-clicking on the error.
Another thing that would be nice is improving the UI for adding extra
clang flags as it is kinda confusing.

I will continue using this kind of setup for the next ~2 years so I am
highly motivated to improve the situation and help you with this.

Alex