Meson or Bazel for the build system

GNOME and many other free software projects have migrated to the Meson build system. However I’m not entirely satisfied by Meson, its DSL (Domain-specific language) has a fatal flaw: all variables are global, the concept of variable scope doesn’t exist (see this issue).

Choosing a build system for a project as large as GNOME (which has between 150 and 200 modules) should not be done lightly. What happened is that a few modules migrated to Meson, then someone has created a GNOME Goal for it, and then almost everybody were migrating to Meson, without any deep thinking, without looking at alternatives and weighing the pros and cons.

In that regard, the Debian project functions better, for example all the discussions about choosing the init system: at least there has been deep thinking before committing to a new technology that has a wide impact on the whole project.

Bazel

I wish that GNOME would have looked and consider Bazel for its build system. And to any big project out there considering a migration to another build system, don’t take the first newer technology that you try, learn and test different build systems, do proofs of concepts, weigh the pros and cons, and consider Bazel.

A short list is worth a thousand words:

  • CVS: Autotools
  • SVN: CMake
  • Git: Bazel

Where to put Meson? SVN++, maybe.

A Bazel vision is that it serves language communities: it should be possible to integrate Bazel with the workflows and conventions of any community of developers.

So why not GNOME, or more generally the Linux free software community? With C or C++, pkg-config, etc.

Comparing the contributor community sizes

As an exercise to the reader, we could compare the contributor community sizes, funding etc, between Meson and Bazel. Like ebassi did between Vala, Rust and Go. I think you already know the answer. The same for GTK vs Qt, or GLib vs the C++ standard library.

Just some thinking of a Saturday afternoon.

14 thoughts on “Meson or Bazel for the build system”

  1. Just because you don’t agree with a decision it doesn’t imply that those who took this decision haven’t thought a lot about it, and weighed various pros and cons. You don’t always need a general resolution to decide—and, in fact, the decision about the init system in Debian was initially taken by the Technical Committee.

    The history of Google-backed build systems is littered with failed experiments, often with little to no notification about their deprecation; at the very least, Meson is maintained by an actual community.

  2. Build systems! Thanks for bringing up one of my favourite topics 🙂

    How many projects have migrated from Autotools to Bazel so far … is it practical to do that yet?

    It’s important to look at Bazel because it has some cool features no other build system has. But Bazel has a wider scope than Meson .. we have to include BuildStream in the comparison too, if we consider how we build GNOME as a whole.

    1. Yeah as I understand it (I’m not a build system expert), Bazel is basically all-encompassing, taking the job of ccache + make/ninja + CMake/Meson/… + something like BuildStream. As a result the caching is a lot smarter.

      Another thing that I like with Bazel is its clear separation between concepts like an executable or a library, and how to construct those (providing compiler and linker flags, etc). As a result Bazel has a higher-level feeling.

    1. At least the DSL of CMake is better than the Meson one. Meson generates faster ninja instructions, but for a lot of software projects it’s not super important, CMake is quite fast too (and as you point out in your article, it can be improved of course).

  3. Bazel is written in Java, so wouldn’t it be dead on arrival in the GNOME community? I guess the good news is it won’t be affected by the recent implosion of Java packaging in Fedora, since it bundles its own special copy of Java. 😉 Along with plenty of other security-critical libraries, like xz and zlib…

    As I recall, we spent about two years debating Meson vs. Autotools vs. CMake before we started porting applications to Meson, and we only managed that because almost everybody seemed to be on board. I’m only aware of one other GNOME maintainer who didn’t want to switch; his stuff still uses CMake. This is the first I’ve heard that you didn’t like it….

    1. I prefer that a big codebase is written in a language like Java instead of a “scripting” language like Python.

      During the beginning of the switch to Meson, and several years before that, I was involved a lot in GNOME, I was subscribed to many mailing lists (but not all IRC channels). I don’t remember a debate with CMake (I just know that Evolution uses CMake). Between Meson and CMake, I think that I prefer CMake now. Maybe the debate was among release team members.

      Anyway, now it’s too late for GNOME. At least Meson is an improvement over Autotools. Maybe in 10 years GNOME will think about switching to something else.

      But for me Meson has a low-level feeling, it provides like a toolkit. From one module to another, the same boilerplate is needed, like with Autotools I need to copy/paste snippets of code.
      With Bazel and its extensibility there is the possibility to provide a framework instead, avoiding boilerplate. Something a little similar with how Ansible roles are defined with a specific filesystem structure, we could imagine a filesystem structure for a Linux desktop app: here is the app icons, here is the *.desktop file, the AppData, etc, with really minimal or no code at all in the build system to support those.

  4. A thing to note about Bazel is that it is not available in Debian or Fedora. Thus if you go with Bazel you’d need to maintain a second build system, too, or otherwise you’d make distro packagers very angry.

    1. This ticket is still open: https://github.com/bazelbuild/bazel/issues/5188

      But yeah external deps is what makes Bazel impractical right now for C/C++ on Linux, even though it’s possible:
      https://blog.envoyproxy.io/external-c-dependency-management-in-bazel-dd37477422f5

      But I think with the extension language of Bazel it’s possible to support pkg-config, it would require some development efforts, and not all Bazel features would be supported (like sandboxing and remote execution, probably, but I’m not an expert).

  5. Hi Sébastien,

    If you want to convince anyone to use Bazel, or to not use meson, which seems to be the point of your article, you should come up with better arguments than ‘I don’t like’ and ‘I prefer’.

    I for one would love to hear more about Bazel, and a fair comparison of the different build systems would be nice. Meanwhile, neither the documentation, the java dependency nor the size of the package make Bazel attractive.

    Cheers.

Leave a Reply

Your email address will not be published. Required fields are marked *