Hi,
On Tue, 2020-10-27 at 19:28 +0000, Chandan Singh wrote:
[...]
> The shell functionality already allows network access for purposes
> like this, and comes in two variants - build shell and runtime shell.
>
> The build shell will have all the build dependencies and sources for
> the element in exactly the same way that they would be staged during
> a
> `bst build`. It can be used to debug builds of the project, for
> example, to iterate on various configuration options.
>
> The runtime shell will provide access to the built artifacts of the
> element and all its runtime dependencies. As such, it is more useful
> for testing the resulting binary.
>
> Both the shells allow network access. As such, they are not meant to
> produce deployable artifacts, but can be very useful for debugging
> purposes. There are probably still many things that could be improved
> in the shell experience. So, I'd be very interested for you to try
> the
> shell functionality and let us know if that works for your use case.
>
> One issue that I can already think of is that if we go with this
> approach, you will also need to have a debugger available in the
> BuildStream project and somehow add a dependency on it for invoking
> the build shell. This topic has been a recurring discussion item, but
> we haven't solved it yet.
> https://gitlab.com/BuildStream/buildstream/-/issues/422 has some
> related background on this.
>
> A couple of references below.
>
> CLI docs:
> https://docs.buildstream.build/master/using_commands.html#invoking-shell
> Shell in action:
> https://docs.buildstream.build/master/tutorial/running-commands.html#run-the-hello-world-program
>
To really make good use of the shell, I should point out that there are
some additional holes you might want to poke in the sandbox, which
BuildStream explicitly supports doing in order to test built artifacts
in your host environment, with the assumption that your host machine
somewhat resembles the target environment where the artifact is
expected to actually run, this is done through the `shell` project
configuration:
https://docs.buildstream.build/master/format_project.html#customizing-the-shell
Currently it is possible to run your apps using the host X server and
the host pulseaudio, and even leverage graphics acceleration from the
host:
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/project.conf#L161
It is of course important to test the deterministically built artifacts
BuildStream produces on real running systems, this is especially true
for the edit/compile/test cycle scenario.
This control over poking explicit holes in the sandbox has so far been
able to handle everything one could need on Linux (we could extend that
this turns out to be untrue, and will probably need to extend this
configuration when adding support for exotic platforms like windows).
Cheers,
-Tristan
