The new command will take an extension directory set up
with `meson-build --sysext` inside a toolbox, and turn
it into a merged system extension on the host.
Namely it will
1. copy the extension directory from the container to the host
2. set up the extension-release file expected by systemd-sysext
3. compile gsettings schemas if necessary (using the merged
schemas directory)
4. install the extension to either runtime or system
5. merge the extension
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
While the toolbox image itself has all necessary dependencies to
build and run the shell, we still need them in the destdir when
building a system extension.
Achieve this by running .gitlab-ci/install-common-dependencies.sh
if it exists, which is the script that is used both for gnome-os
system extensions and mutter's CI image.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
When specified, the project is installed to a separate destdir
inside the container instead of the container's root filesystem.
This can be used to install several projects into a common extension
directory:
```
$ (cd mutter; meson-build.sh --sysext) &&
(cd gnome-shell; meson-build.sh --sysext)
```
We will later add a separate command to extract the directory
from the container and turn it into a system extension suitable
for use with systemd-sysext.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
The dist command only needs an up-to-date build directory, it
does not require the project to be installed first.
While the install step is generally quick, leaving the container
file system alone can save a rebuild after the dist is done
(for instance when testing a branch, then temporarily switching
to the release branch for dist).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3497>
Handing the various options to different meson commands in meson-build
gets a bit tedious. Instead of handling them all on the toplevel,
split out *_command() functions that generate the commandline for
the corresponding meson command.
That way, options are handled locally where they matter, which
makes future changes and additions a bit easier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3497>
The main use of the --dist flag is as a fallback when the CI
dist job doesn't work for some reason. The gnome-shell tarball
now needs the --include-subprojects flag, and it doesn't hurt
for mutter/gnome-shell-extensions, so just add it when --dist
is specified.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
It's useful when the existing build directory became invalid,
for instance after a meson update, and exposing it directly
from the wrapper script is more convenient than removing the
directory or entering the toolbox manually to invoke meson.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3113>
Unlike the other scripts, meson-build currently doesn't set
the `-e` option. The script is mainly a wrapper around a single
toolbox call, but it means that any errors during option parsing
print a warning, but are otherwise ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3113>
Now that we have a collection of scripts around the toolbox
workflow, it makes sense to add a brief overview over the
available tools.
For now it's just located in the corresponding tools folder,
but it gives us something to point to once we overhaul the
toplevel documentation as part of the wiki migration.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3040>
Wrapping the gnome-shell call with `dbus-run-session` is *mostly*
enough for testing, but not quite.
When running without gnome-session, the wayland display is not
propagated to the D-Bus daemon, so any app that is D-Bus activated
still opens in the host session.
This can be worked around by using a specific wayland-display name
and exporting it to the `dbus-run-session` environment up-front.
At this point the invocation is finicky enough to justify another
convenience script. This also gives us a place to expose some
useful features for testing, like forcing a right-to-left layout
or simulating the greeter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
We don't require any build steps other than the standard meson
commands, but entering a toolbox and running 2-3 meson commands
still adds some friction.
Add a small convencience script that
- finds the toplevel source directory (similar to `jhbuild make`)
- enters the speficied toolbox (or the configured default)
- automatically picks a build directory based on the toolbox name
- builds and installs the project to /usr (inside the toolbox)
It also allows specifying meson -D options to change the build
configuration, and to optionally run `meson dist`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
Setting up more than one gnome-shell toolbox is uncommon, and users
shouldn't have to specify --set-default for other tools to pick the
right default.
It would be possible to detect the number of containers that were
created from the shell toolbox image, but the far easier option is
to just set up the first container as default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
Out of the box, the container images only support US English. It
can sometimes be necessary to use a different locale, so add
a convenience flag to enable support for additional locales.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The container is useless for building or running gnome-shell unless
it includes the correct mutter version, so building it by default
makes sense.
However a manual build can be significantly faster when there's an
existing build dir, so add an option to skip the automatic build.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
A toolbox created by the script can be used as the base of a pet
container that is manually updated with new dependencies over time
and accumalates additional packages; or it can be used as a deposable
container that is recreated each time the dependencies change.
To make the latter case more convenient, add a --replace option
that deletes an existing toolbox before creating the new one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The script is a thin wrapper around `toolbox create`, mainly to
avoid the tedious image names. In addition, it allows us to
ensure that the container includes a matching mutter version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
