Skip to content

Draft: Add meson as an experimental alternative build system

Aydın Mercan requested to merge aydin/meson-experiment into main

This MR adds meson as an experimental and development only alternative build system. It will serve as the bedrock for evaulating meson as a possible future for BIND9.

Missing Functionality

  • Installation
  • System tests
  • Building documentation
  • Some of the fallback logic
  • Some of the build options (fuzzing, dnsrps, fixed rrset-order etc.)

Case for Meson

  • Speed: Meson is noticably faster to setup and build than automake/autoconf. The improvements will likely add up in CI and development.

  • Readability: Readability is a subjective criteria but meson is generally regarded as easier to read compared to CMake and automake/autoconf.

Case against Meson

  • Dependency: One of the advantages of autoconf is the ability to build from release without needing itself. However, meson is required to build a project which could introduce version incompatibility depending on the build platform. Fortunately, meson emits a warning if a used feature might not exist in a project legal version specified in meson_version. This should be enough to establish a baseline version with confidence. Also, if needed, downgrading to >=0.59 should be possible trivially at the cost of some verbosity. This greatly increases the range of usable meson versions in stable distributions.

  • Portability: Meson in written in Python. Because meson and ninja is present in pretty much every platform we target and system tests use Python as well, this might be a reasonable ask in the end.

Fortunately, for people that do not want to bootstrap python beforehand, muon will likely be a usable alternative.

A word about muon

There are multiple in-progress implmentations of meson. However, apart from muon, they seem to be abandoned.

Muon itself is written in C and has small requirements to bootstrap and contain the functionality needed to build BIND:

  • A C99 compiler
  • POSIX sh
  • libpkgconf/pkgconf

The main branch of muon targets meson 1.1.0 compatibility. Most of the functionality has already been implemented and it was trivial to write using the common functionality. The only noticable difference is the inability to pass generated objects in the objects: keyword argument. Moving the objects from objects: to source fixes the issue but we should wait for muon to have a release first.


An example benchmark in a Ryzen 9 7900 machine:

$ hyperfine --warmup 5 --prepare 'ninja -C build-meson clean' 'ninja -C build-meson'`
Benchmark 1: ninja -C build-meson
  Time (mean ± σ):      3.047 s ±  0.035 s    [User: 55.479 s, System: 12.530 s]
  Range (min … max):    2.994 s …  3.102 s    10 runs

$ hyperfine --warmup 5 --prepare 'make clean' 'make -j24'
Benchmark 1: make -j24
  Time (mean ± σ):     15.841 s ±  0.121 s    [User: 67.247 s, System: 9.824 s]
  Range (min … max):   15.590 s … 16.078 s    10 runs

For setup:

$ hyperfine --warmup 5 --prepare 'rm -r build-meson' 'meson setup -Dcmocka=enabled build-meson'
Benchmark 1: meson setup -Dcmocka=enabled build-meson
  Time (mean ± σ):      4.064 s ±  0.086 s    [User: 2.383 s, System: 2.095 s]
  Range (min … max):    3.977 s …  4.223 s    10 runs

$ hyperfine --warmup 5 --prepare 'make distclean' './configure'
Benchmark 1: ./configure
  Time (mean ± σ):      8.432 s ±  0.117 s    [User: 5.603 s, System: 3.164 s]
  Range (min … max):    8.218 s …  8.588 s    10 runs

However, keep in mind that the builds aren't one-to-one:

  • automake/autoconf builds documentation but meson doesn't
  • meson also builds every unit test but automake/autoconf doesn't
  • Missing functionality might add a couple source files and does add extra probing (but hopefully shouldn't be significant)


The build hierarchy is pretty flat with almost everything done in the main file. Build files inside non-test subdirectories are only used for code generation and filling the source arrays. An alternative would be to place the library/executable definitions inside the relevant subdirectory. This is mostly a stylistic choice.

WrapDB and downloading dependencies is a non-issue for us since it requires writing wrap files explicitly and has been disabled by default via the wrap_mode=nofallback project option as a measure.

Merge request reports