Re: [BuildStream] Summary of the 'Staging multiple elements in bst shell' discussion at the gathering

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

Hi James,

I was not present at this discussion, thank you for summarizing it in
detail !

At a certain point below, I have a very hard time following what is
being talked about, I don't think the right terms are being employed,
and perhaps if you changed some words here I might understand more.

On Mon, 2019-02-04 at 16:36 +0000, James Ennis via BuildStream-list wrote:
> Hi all,
[...]
> # Summary of discussion at the gathering
> First of all, we discussed what the desired and viable use-cases were 
> here. It was agreed that for now, it makes sense to be able to stage 
> multiple runtime elements in the shell so that we could, for example, 
> include our favourite debugger/text editor. However, regarding the 
> question of staging multiple elements into the build shell - it doesn't 
> make sense to have multiple build environments in the same shell. 

There are runtime dependencies and build time dependencies, there is no
such thing as "runtime elements" and there *is* such a thing as "build
elements".

When we say, that staging multiple elements into a build shell doesnt
make sense because it doesnt make sense to have multiple build
environments... maybe you mean that it does not make sense to stage two
separate elements for building ? (i.e. with their sources staged) ?

Does this somehow remove the ability of staging additional
complementary elements in the context of invoking a build shell for a
given element ?

I see that the element you are building is the one which should
determine the environment, so there should always be one element
hardwired to be "the build element" when launching a build shell so
that this is always clear, but I don't think this effects our ability
to stage more artifacts.

Further, we should recognize that this is not specific to build shells,
the environment variables specified by a given target element will also
be the ones used for a regular `bst shell` which you might use to
launch and test a graphical application on your laptop.

I appears this is the same problem for launching build shells which
extend the target with multiple elements, as it is for launching
regular runtime shells which do the same.

> We 
> should have exactly one element that sets the build environment and the 
> ability to add more runtime elements into the shell.

Reading this phrase another time around I think we basically agree on
this.

However, please note that there is no such thing as a "runtime
element", basically you *do* need one element to decide on the
environment (regardless of whether `--build` was specified), and asides
from that there don't seem to be any restrictions as far as I can see.

Of course you can only stage dependencies that are built in a shell,
except for the special `--build` toplevel target who's sources are
staged instead of it's artifact (which is rather the only special case
in launching shells).

I wonder if you have considered staging order in all of this (incase
you want to explicitly prioritize conflicting dependency trees for the
overlaps), and if you have consider the `--directory` options discussed
before.

I.e. you might want to stage a literal host directory which has a bunch
of host tools in it which work for the specified arch, and you might
want to stage it before or after the artifacts, allowing you to get
your host tools into the shell without creating any elements or
interacting with the project data.

Cheers,
    -Tristan