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

[Aleix Pol]

On Tue, Sep 13, 2016 at 2:37 AM, 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 looked into the problem in the past, I would say that if we take
this path we risk overlook the big picture.

It's not really about being able to remotely execute make on a
different computer or virtual environment because we also want to
replicate the environment. For example, we want to have all headers
available, preferably the same version that will be executed.

I think that for us our best bet is to properly integrate bundling
systems where the platform is more defined than on a remote device.
Also it will give us better semantics on what deploying means that we
can use for proper integration in the GUI.

Aleix