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.
The initial plan is to focus on targeting Linux from Linux, OS X and WSL. This just to limit the amount of moving pieces. We can look at targeting other platforms from any input platform later on.
* 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.
I much prefer us to keep focussed on the remote execution client only support for OS X and WSL first. And to then expand into making builds work locally on either platform.
Agree?
Cheers,
-Tristan
Cheers,
Sander
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
