Add a Meson build system

[smcv]

• Add a Meson build system

  This allows bwrap to be built as a subproject in larger Meson projects.
  When built as a subproject, we install into the --libexecdir and
  require a program prefix to be specified: for example, Flatpak would use
  program_prefix=flatpak- to get /usr/libexec/flatpak-bwrap. Verified to
  be backwards-compatible as far as Meson 0.49.0 (Debian 9 backports).

  Loosely based on previous work by Jussi Pakkanen (see Basic build of Bubblewrap with Meson. #133).

  Differences between the Autotools and Meson builds:

  The Meson build requires a version of libcap that has pkg-config
  metadata (introduced in libcap 2.23, in 2013).

  The Meson build has no equivalent of --with-priv-mode=setuid. On
  distributions like Debian <= 10 and RHEL <= 7 that require a setuid bwrap
  executable, the sysadmin or distribution packaging will need to set the
  correct permissions on the bwrap executable; Debian already did this via
  packaging rather than the upstream build system.

  The Meson build supports being used as a subproject, and there is CI
  for this. It automatically disables shell completions and man pages,
  moves the bubblewrap executable to ${libexecdir}, and renames the
  bubblewrap executable according to a program_prefix option that the
  caller must specify (for example, Flatpak would use
  -Dprogram_prefix=flatpak- to get /usr/libexec/flatpak-bwrap). See the
  tests/use-as-subproject/ directory for an example.

[smcv]

I'm not sure whether we will be moving Flatpak to meson, but I'd like to at least be able to consider it.

Another project that might switch to building bubblewrap as a subproject is steam-runtime-tools, which includes a mechanism to run Steam games in containers, used by recent versions of Proton.

[smcv]

The test script is timing out during meson dist but not during the main build, I'm not sure why.

[cgwalters]

This looks sane to me offhand. But a general concern here is that we still have some special casing in the buildsystem around e.g. suid handling, so duplicating that is a nontrivial concern.

If we see the autotools as on their way out, i.e. heading towards one build system that this seems more palatable. We could merge but note it's not the default or so?

[smcv]

we still have some special casing in the buildsystem around e.g. suid handling

I think that's mostly a relic of the situation in very old versions where the /usr/bin/bwrap binary ended up different, depending whether you configured it for the setuid or modern setup.

What's left is just the build-system goo to set the setuid bit itself, which I deliberately didn't replicate in the Meson build (at least for now) because I think it's often more appropriate to handle that in a higher layer, such as distro packaging. In particular, if you're installing as a nonzero uid into a DESTDIR, possibly with fakeroot, then I'm not really comfortable with making the executable setuid.

If we see the autotools as on their way out, i.e. heading towards one build system that this seems more palatable. We could merge but note it's not the default or so?

I personally do see Autotools as on their way out, particularly in the GNOME-adjacent and freedesktop.org ecosystems; I did this as an enabler for Flatpak potentially moving to Meson eventually, which is why there's explicit test coverage for using bubblewrap as a subproject.

[smcv]

The test is still timing out during one of the automated tests, but only on CI (not on my laptop) and only during meson dist (not during meson test).

The part of the test that is getting stuck seems to be one that juggles subprocesses using fifos on the filesystem and shell process manipulation, which seems like something where randomly deadlocking is a relatively likely failure mode.

@cgwalters, what do you think about the idea of allowing some of the tests to depend on GLib, as I wondered about in #404? That would put us in the same situation as dbus, where the "production" part of the package has minimal dependencies, but full test coverage requires GLib - which might be a good way to keep dependencies minimal, while not having to write unit tests with one hand tied behind our backs (it's worked well for me in dbus, anyway).

[smcv]

WIP. There's still a test failure during meson dist, but only on Github CI, not on my laptop; and only during meson dist, not meson test. With the rebase onto #438 I've isolated it to test-specifying-pidns.sh. Maybe meson dist is leaking a fd down into the test or something?

[smcv]

Please could you take another look at this? There's renewed interest in moving Flatpak to Meson (flatpak/flatpak#2241) for which this is likely to be a prerequisite.

Another project that might switch to building bubblewrap as a subproject is steam-runtime-tools, which includes a mechanism to run Steam games in containers, used by recent versions of Proton.

This is indeed now using bubblewrap as a git subtree, but because bubblewrap doesn't have a Meson build of its own, I had to use a hack. I'd prefer to do this in a more supportable way!

There's still a test failure during meson dist, but only on Github CI, not on my laptop; and only during meson dist, not meson test

This seems to have been resolved at some point, and CI is now passing.

[cgwalters]

Looks sane to me!

[eli-schwartz]

This is indeed now using bubblewrap as a git subtree, but because bubblewrap doesn't have a Meson build of its own, I had to use a hack. I'd prefer to do this in a more supportable way!

Just... for the record, next time you need to hack around support like this I suggest using https://mesonbuild.com/Wrap-dependency-system-manual.html#wrapfile-with-meson-build-patch

It's a bit less hacky than #include <subprojects/......../*.c>. :)