replace dale, rez, tinyrick, and cmake with meson

[mcandre]

https://mesonbuild.com/

Depending on how well Meson actually works.

• Does it provide a complete stock clean task that deletes standard generated files?
• Does Meson get confused when attempting to build the same Meson host project directory from WSL and PowerShell? Will I still have to remember to clear away Meson internal files each time I switch testing from one of these environments to the other?
• Does it run in an out-of-tree manner by default?
• Does it have a mature, community supported toptal gitignore template?
• Does it support Windows and FreeBSD (as some quick canaries for evaluating portability)?
• How cumbersome are Meson build commands?
• What hellspawn DSL does it use for the configuration format?
• Does it require Python, Lua, Ruby, Perl, the kitchen sink to be installed?
• Does it provide an easy, first party way to declare arbitrary command line build steps?
• Does Meson have command primitives for (portably!) ensuring nested directory trees exist, forcibly updating file modification timestamps, recursively copying directories, recursively and forcibly deleting directories, redirecting command output streams?
• Does it comes with a unit test framework for C/C++ projects?
• Does it wrap individual programming language unit test suite commands with a reusable test suite command?
• Does it have packages on Chocolatey, Homebrew, apk, apt, yum, pkg, opkg, emerge, ipkg, pacman, urpmi, ...?
• How consistently is the Meson package named across the various OS-level package managers?
• What quality is the documentation?
• How well does it integrate with C, C++, GCC/G++, Clang/LLVM, MSVC, Clang-CL, and Conan?
• How well does Meson support integration with libFuzzer testing?
• Can meson help to recurse for derpy linters and code formatters, like clang-format, that lack built-in directory recursion?
• How well does it integrate with D and Dub?
• How well does it integrate with Rust, Rustup, and Cargo?
• How well does it integrate with VSCode? Will I need to turn off the VSCode highlighting for Meson configuration files due to the plugin acting the fool?
• Does the configuration file use a silly ".txt" file extension? Is it TOML, or at least YAML? Sigh, do I need another excuse to have to YAML lint yet another YAML file?

[mcandre]

Appears to be integrated and/or depend on, Ninja and Python (v3). Could be better, but not terrible.

No other dependencies, at least for the Homebrew formula.

[mcandre]

It has a CLI help menu.

The Homebrew formula has a man page.

[mcandre]

The package appears to be relatively consistently named, which is convenient. It's just "meson," and yes it has a PyPI package to supplement Homebrew.

It has a GitHub entry (either mirrored or normal).

https://github.com/mesonbuild/meson

The latest release of Meson is currently v1.1.0, which was released last week. The Homebrew formula already has the latest version integrated.

The Chocolatey version is out of date by one minor release version.

[mcandre]

https://pkgs.org/search/?q=meson

Alpine Linux already has the latest Meson release.

Debian and Ubuntu still have ancient, pre-1.0 Meson releases. Which means using requirements-dev.txt to provision Meson. Which means we should not use Meson tasks to provision Meson; we will still require a separate provisioning script (ugh).

There are some Ubuntu PPA's of unknown quality and maintenance level, still at least a minor version behind.

Other Linux flavors, (do we need to even bring up the laggard CentOS?) are also very often stuck at pre-1.0 meson releases. Even NetBSD, scion of source-based builds, is stuck there.

Somehow, FreeBSD amd64 and aarch64 provide different Meson versions.

We could wait five years and still not get v1.1.0 merged into all the OS package distributions.

Void Linux has Meson v1.1.0. Go Void Linux!

Yeah, we'll be using pip to get Meson. Or Ansible some day if we really want to be comprehensive about dev environment provisioning.

[mcandre]

We may never need them, but some org resembling Meson official, has various Docker images up on Docker Hub:

https://hub.docker.com/u/mesonbuild

The Ubuntu one is "rolling" rather than pinned.

No documentation or example usage. They use some kind of hairy install shell script instead of a plain vanilla, direct RUN, OS-specific install command to obtain Meson. Likely via pip. Which again, means having to resolve issues about Python version(s) as part of the stack and running safety check and other CVE scans.

[mcandre]

meson has a --version flag.

[mcandre]

meson has decent exit status semantics for invalid commands.

[mcandre]

meson has an official .PKG for macOS users.

meson does not digitally sign this install media in a way that plays nice with Apple's silly third party app gatekeeper.

[mcandre]

The Meson tutorial is one of those obsessed with running silly scaffolding commands, rather than explaining the configuration system text files.

[mcandre]

The meson.build build configuration file appears to be some cmake-like or Python-like DSL.

[mcandre]

Meson has a concise and yet comprehensive gitignore template:

https://www.toptal.com/developers/gitignore/api/meson

[mcandre]

VSCode shows a weird prompt with too little explanation about what it's asking for. VSCode fails to highlight the builddir directory (a neutral directory to git) as an essentially ignored VCS directory. It sticks out like a sore thumb.

Meson has a ridiculous semantic that it must be run with the context of an out-of-source build directory. The directory is conventionally named builddir (yes, with the stutter).

Meson commands vary in support and meaning of a -C flag to change directory to builddir.

We can't quite alias meson to meson -C builddir. Even if we can, the shim wouldn't be very portable.

So those are the cons. One pro is that we finally have a C/C++ build tool that doesn't take a dump of internal files all over the top-level project directory. If only the Meson authors had thought to set their child process working directory accordingly.

[mcandre]

Meson is crap at cleaning up its own internal files by default, just like cmake.

That doesn't necessarily mean impossible.

[mcandre]

meson compile -C buildir works. Almost as much of a mouthful as the equivalent cmake command.

[eli-schwartz]

We may never need them, but some org resembling Meson official, has various Docker images up on Docker Hub:

Sorry, for the record these docker images aren't for users to run meson in a docker container -- those are our (@mesonbuild) "official" containers for officially running the linux portions of the Meson internal CI with a wide variety of frameworks, compilers, etc. installed to maximize unittest coverage. e.g. the ubuntu-rolling one has GCC, clang, rust, Java openjdk, dub, a mingw compiler, wine, boost, fortran, vala, objc, GNUStep, mono, wxwidgets, Qt5, gtk3, vulkan, sdl2, doxygen, nasm, and even cmake...

Appears to be integrated and/or depend on, Ninja and Python (v3). Could be better, but not terrible.

No other dependencies, at least for the Homebrew formula.

A lot of effort has gone to making sure that meson's build files format doesn't require python. Compare to autotools, which cannot be ported to anything other than m4/sh/make due to leaky implementation details...

Which means that it's feasible and practical to rewrite meson in another programming language if it's ever decided that writing it in python has cramped our style. It also means that https://sr.ht/~lattis/muon/ can exist in practice -- a c99 implementation of meson that has reasonably complete support for any part of meson needed to build, test, and install C/C++ projects with custom build steps.

It is packaged in Homebrew, Alpine, Debian, Gentoo, FreeBSD... there's a Void Linux package currently under review.

Does it have a mature, community supported toptal gitignore template?

Meson has a concise and yet comprehensive gitignore template:

https://www.toptal.com/developers/gitignore/api/meson

This is mostly not necessary since 2021 (unless you're stuck on old versions of meson <0.57): https://mesonbuild.com/FAQ.html#how-do-i-ignore-the-build-directory-in-my-vcs

tl;dr meson automatically guarantees that git will not see the build directory.

The # subproject directories section of the gitignore template is still relevant.

[eli-schwartz]

Can meson help to recurse for derpy linters and code formatters, like clang-format, that lack built-in directory recursion?

Yes, for builtin support for clang-format, clang-tidy: https://mesonbuild.com/Code-formatting.html

How well does it integrate with Rust, Rustup, and Cargo?

This is a definite pain point. Rust/Cargo is not easy to integrate into other build systems, but meson does have support for building rust code with rustc. Depending on external crates is complicated and manual, but can be done... it is an explicit goal of a meson core developer to make this easy, which means to an extent reimplementing much of cargo without using cargo. This is required for Mesa. Gnome is also interested in it, and so is gstreamer.

It is possible to run cargo as a custom build step if strongly desired, I suppose. But I'm strongly looking forward to Rust finally having a second build system which is practical to use for writing Rust software. We can't just be locked into Cargo forever...

Does the configuration file use a silly ".txt" file extension? Is it TOML, or at least YAML? Sigh, do I need another excuse to have to YAML lint yet another YAML file?

Since meson 1.1 the options file no longer has to have the silly ".txt" file extension. The build file never used any such thing.

https://mesonbuild.com/Release-notes-for-1-1-0.html#support-for-reading-options-from-mesonoptions

[mcandre]

Thank you for the feedback.

Sticking with language specific build tools for the most part.