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.


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.