[BuildStream] Dependencies in a sysroot

[Valentin David <valentin david codethink co uk>]

Hello,

I want to propose a new feature for BuildStream that we have been
needing for Freedesktop SDK.  It is in my opinion relatively simple and
would solve many problems in Freedesktop SDK.

While this is related to cross compiling, it is needed for bootstraping
in general. So do not let the mentions to cross-compiling make you hate
this feature.

Use of sysroot
==============

Sysroot is a directory where the root of the system you are building
resides. There are two reasons why you want to use a sysroot:
bootstrapping, and cross compiling.

For cross-compiling, it is obvious, you cannot run the same system as
the one you are building.

For bootstrapping, it makes sure that you make a clean system with the
remaining files. For buildstream's point of view, this is not the
problem, but it does avoids overlaps. In the case of the GNU toolchain,
glibc needs GCC, and GCC needs glibc. And for that reason, it is easier
to build in a sysroot.

GCC and binutils can handle sysroots. They can be configured with a
default sysroot. You can also pass as parameter the sysroot you wish to
use. They will find libraries in the sysroot instead of from the root.

Generally, a sysroot does not have to stay the same. You can take an
existing image, put it in the sysroot you want, and compile and install
things against it. It does not matter if this image has not been built
using a sysroot, or if the sysroot was different. There is nothing in
this image that reflect the sysroot.

Current way in freedesktop-sdk
==============================

Since we cannot import dependencies into a sysroot, we instead make
artifacts that contain a sysroot.

And in order to remove the sysroot, we have a script element with
"install-root" to be defined as the sysroot.

 loss of granularity in the dependencies
 ---------------------------------------

In order to reduce the number of script elements, we compose the
bootstrap phase. So that means we cannot depend on specific parts of
the bootstrapped elements. Some the elements in the bootstrap are build
dependencies for some other elements, and they should not necessarily
come along. An example is file.bst.

 split rules
 -----------
 
Element defined split rules do not go through the script element. For
the moment we have 2 script elements, one for "devel" files, and one
for everything else. Then we make a stack of those two elements.
However if we want to be sure to have correct split, we should make one
script element per split domain.

 shell
 -----

Shell does not work in sysrooted artifacts, because the files are not
placed where they should for running. This is a recurring issue that
new comers complain about.

 We cannot combine bootstraped and non bootstraped
 -------------------------------------------------

In theory, there should be nothing preventing us from building with a
sysroot and depending on something that was built not needing a
sysroot. For instance we could introduce later in the pipeline,
bootstraped compilers that are easier to compile with a sysroot. This
if it comes with separate libraries that need to be compiled in the
bootstrap of this compiler.

Proposed solution
=================

Let's consider these dependencies for readline.bst (ficticious, but
inspired and simplified from Freedesktop SDK).

 readline.bst
 ------------

depends:
- filename: glibc.bst
  sysroot: "%{sysroot}"
- filename: ncurses.bst
  sysroot: "%{sysroot}"
- filename: system-image.bst
  type: build
- filename: sysroot-compiler.bst
  type: build

 -------------

(note in this case the ncurses.bst should probably depend on glibc.bst
anyway, and sysroot-compiler.bst should depend on system-image.bst, but
this is just an example).

In this case I want artifact of glibc.bst and all its runtime
dependencies to be mounted at "%{sysroot}". The same for ncurses.bst.
And then I want system-image.bst and sysroot-compiler.bst and all their
runtime dependencies to be mounted at "/".

Note that glibc.bst and ncurses.bst are of type "all". The artifact of
readline.bst we are currently building will depend at runtime on
glibc.bst and ncurses.bst. The sysroot is ignored for runtime. If you
run a shell on the built artifact, both glibc.bst and ncurses.bst need
to be mounted in "/".

However what happens when we have an a element depending on
readline.bst. Let's say we have bash.bst with the following dependency
section:

 bash.bst
 --------

depends:
- filename: readline.bst
  sysroot: "%{sysroot}"
- filename: system-image.bst
  type: build
- filename: sysroot-compiler.bst
  type: build

 --------

In this case glibc.bst and ncurses.bst will be mounted in the same
sysroot as readline.bst, by following runtime dependencies. However the
value of the sysroot will be the one defined in bash.bst, and not the
one in readline.bst. So if we redefined variable "%{sysroot}" in
bash.bst all dependencies would go in that new sysroot.

sysroot configuration is ignored while walking dependencies. Only the
top level ones are considered. Indirect runtime dependencies are pulled
with the same sysroot as the direct build (or "all") dependency that
required it. And this even if that dependency did not have any sysroot.

The install-commands of an element should not install in a sysroot. It
should install in the standard DESTDIR. Elements do not know if they
will be used in sysroots. They might be used sometimes with or without
sysroot.

Also "sysroot" configuration does not make sense with "runtime" type of
dependencies, it does not mean anything. Only "build" and "all"
dependencies should be allowed to have a sysroot.

It is possible in theory to pull more than once a same dependency with
different sysroot. In that case it is really pulled several times.

While most of the time we need only one sysroot, there is nothing that
should prevent us from having several sysroots. However to avoid with
typos in the sysroot, to reduce verbosity, and to improve clarity, we
could of course group depenencies by sysroot instead of repeating the
sysroot configuration entry.