Draft: new: dev: add meson as an experimental alternative build system

This MR adds meson as an experimental and alternative build system. It will serve as the bedrock for evaluating whether transitioning the build system into meson is worth it or not.

Missing Functionality

• Fixed rrset build option: This feature is scheduled for removal in a 9.21 release so there isn't much point to add it to meson.
• Installing the ARM and its sed-based fallback for old versions of sphinx-build: Packages might decide differently on handling the single page and multi page HTML documentation so I think it is best for them to copy the folder directly instead of a million different build options.

Case for Meson

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

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

• Developer Ergonomics: Meson produces a compilation database, doesn't require libtool wrapping of executables/debuggers and offers JSON based build introspection.

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. Currently we use 1.0.0 as the minimum version but should work with 0.63.

• Portability: Meson in written in Python which has some implications for packagers working with BIND. However considering the various widespread packages using meson (QEMU, systemd, OpenRC, Knot etc.) this might be a reasonable ask.

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

A word about muon

There are multiple in-progress implementations 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 0.3 version of muon implements enough of meson to be usable with BIND.

Speedup

Hyperfine has been used for benchmarking in different developer machines. While not a scientific work, the speedup is clear as day and can be done by anyone with the following commands:

• hyperfine --warmup 5 --prepare 'ninja -C build-meson clean' 'ninja -C build-meson'
• hyperfine --warmup 5 --prepare 'make clean' 'make -j'
• hyperfine --warmup 5 --prepare 'rm -r build-meson' 'meson setup -Dcmocka=enabled build-meson'
• hyperfine --warmup 5 --prepare 'make distclean' './configure'

{
    "fields": [
        {"key": "m", "label": "meson"},
        {"key": "a", "label": "automake"}
    ],
    "items": [
        {"m": "4.025 ± 0.156", "a": "13.510 ± 0.187"},
        {"m": "47.627 ± 0.806", "a": "85.813 ± 0.854"},
        {"m": "12.533 ± 0.237", "a": "31.684 ± 0.120"}
    ],
    "caption": "Build time (s)"
}

{
    "fields": [
        {"key": "m", "label": "meson"},
        {"key": "a", "label": "autoconf"}
    ],
    "items": [
        {"m": "2.603 ± 0.019", "a": "4.972 ± 0.150"},
        {"m": "4.064 ± 0.086", "a": "7.077 ± 0.052"}
    ],
    "caption": "Configuration time (s)"
}

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

Miscellaneous

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.