Re: [BuildStream] Bst support on MacOSX and Windows

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2018-08-09 at 19:14 +0100, Phillip Smyth via BuildStream-list wrote:
> Hi Everyone,
>
> I have recently begun work on making BuildStream run on MacOSX and Windows 10
>
> The issues for these and my current plans are on gitlab [1] [2]
>
> So far I have managed to make MacOSX pass unit tests, while only having to skip a couple of tests (more on 
> this later)
> But am having less luck on Windows, due to WSL (Windows Subsystem for Linux) currently not supporting fuse.
>
> As I understand it, the Microsoft team are currently working on fuse compatibility with WSL, but there is 
> no timeline on when that will finish.
> So for now I am open to suggestions on ways to get around this issue.
>
> The current plan is to use remote execution (currently in development) to achieve this since, as I 
> understand it,
> that would remove the need for fuse entirely from the client machine.
> But the future goal is to have full local WSL builds possible, so I feel it is worth beginning the 
> discussion on it now

Hi Phillip,

I think the appropriate steps to take for WSL builds, are to create the
appropriate tickets downstream and track the appropriate tickets from
upstream to keep things up to date.

After that, it's plausible to consider alternatives to FUSE etc. This
part will most probably need to be taken care of in the new BuildBox
layer which will be the place to develop cross-platform support for our
sandboxes.


That would mean:
* Find out what Linux syscalls BuildStream requires
* Find out which subset of these remain unsupported by WSL
* Create a tracking ticket in BuildStream representing the intent to
  have real support for building Linux on Windows via WSL (different
  from the existing remote-execution only ticket)
* Create a ticket in BuildStream for each of the missing
  features in WSL
  * Each of these tickets should refer to an upstream bug report
    which requests the functionality in upstream Windows WSL
  * Ideally we should at least comment on the upstream windows
    tickets and express our interest in the feature, and link
    to our downstream ticket in our comment on the upstream ticket.
  * Mileage may vary... Microsoft might not be the best actor in
    terms of software development and collaboration, I'm not familiar
    with their issue tracking or if they even allow the public to
    file tickets.
* Mark all of these issues as "related" (because gitlab still does
  not support issue dependencies, a crucial issue tracking feature,
  see: https://gitlab.com/gitlab-org/gitlab-ee/issues/2035) to indicate
  they are related; each of these tickets should at least mention that
  they *block* development towards supporting builds through WSL.
  

The first step is a bit complicated and requires an investigation; it
is not enough to run BuildStream's tests alone.

For instance, you have hit a wall with FUSE, but FUSE is used in the
first steps of constructing a sandbox environment; the next hurdle
hiding behind FUSE is whether `bwrap` will be able to create a user
namespace; so we should at least try to run `bwrap` on windows and find
out if user namespaces are supported yet.

Seeing as WSL, from what I understand, is interested in supporting the
server market (running linux servers in windows), it stands to reason
that they care about containerization features like namespaces; so this
might already work.

I will leave the OSX questions out for this email, I think deeper
investigation is needed on the error message you are encountering, but
I think OSX will be much easier to support than windows.

Just some points of interest:
* With WSL, we really are building Linux on windows
* With OSX, we will *not* be building Linux systems, we will be
 
building binaries which target native OSX systems.
* With native windows, we could potentially build native windows
  * It will be interesting when the BuildBox sandbox supports this,
    so that we can slave windows machines as build slaves in a
    BuildGrid as well as building natively on windows
* With OSX, we have a POSIX like environment, so the work to get
  it working should be much less.

Cheers,
    -Tristan