Re: Windows, OS X

[Sander Striker <s striker striker nl>]

Hi,

On Mon, Jun 4, 2018 at 8:49 PM Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

On Tue, 2018-05-29 at 15:21 +0200, Sander Striker wrote:
> Hi,
>
> First let me reiterate the goals of the proposal for Remote Execution
> (https://mail.gnome.org/archives/buildstream-list/2018-
> April/msg00006.html):
>
> > Remote execution enables BuildStream to run build jobs in a
> distributed network instead of on the local machine. This allows
> massive speedups when a powerful cluster of servers is available.
> >
> > Besides speeding up builds, a goal is also to allow running builds
> on workers that use a different execution environment, e.g., a
> different operating system or ISA.
> >
> > The goal is not to offload a complete BuildStream session to a
> remote system. BuildStream will still run locally and dispatch
> individual build jobs for elements with the existing pipeline.
>
> Even when the target platform is Linux, there is a large set of
> developers on either OS X or Windows [laptops].   As we are
> considering different execution environments on workers, we can also
> start considering supporting BuildStream natively in these
> environments.
> Assuming the scope to be limited to remote execution only for now,
> then I think we should aim to support OS X and Windows, but limited
> to Windows + WSL (https://docs.microsoft.com/en-us/windows/wsl/about)
> .
> Once the remote execution sandbox backend is in place, I think the
> complexity will not be too bad.  But curious to here of any pitfalls.

So there are a few separate things here:

  * Different execution environments, to be available with
    remote execution.

  * Guaranteed linux/abi execution environment, to be virtualized
    on a variety of platforms.

  * Portable BuildStream frontend/core.

All of these things desirable...

I think that WSL is interesting for people building linux but using a
windows laptop to do so, less interesting with remote execution where
you might as well have a real linux runner (rather I'd very much like
to use a native windows sandbox remotely, while running BuildStream on
my linux laptop).

 

Still, if we were to have a portable BuildStream frontend which runs on
windows to build a linux firmware, then implementing a WSL build
sandbox would be a good starting place.

I was proposing to start small :).  When we have a portable

buildstream frontend/core, which I think can include remote execution

support, we have a good starting point to iterate on to get to the more

ambitious multi platform support.

After that we could be looking into how we can do sandboxing on Windows, OSX

and Linux.  Putting some research into https://github.com/opencontainers

is probably a good idea, as a step towards multiplatform sandbox support.

While I agree that supporting your use case (Linux -> Windows) is nice,

I would argue that the majority use case is the other way around.  That

said, implementing specific remote workers for certain platforms is a bit

more orthogonal to BuildStream core.

Cheers,
    -Tristan

Cheers,

Sander 

--

Cheers,

Sander