Add support for building with Meson

[mikecrowe]

The Meson[1] build system makes it easier incorporate third-party libaries into a project if they also build using Meson.

Let's add a minimal Meson build that's compatible with the CMake build, along with a GitHub workflow to check that it builds and that at least the simplest SelfTest runs.

The handling of catch_user_config.hpp is inspired by BUILD.bazel and doesn't attempt to support any configuratons options. Such features could be added later.

Meson strongly discourages using wildcards to specify sources, so the source and header lists are copied from CMakeLists.txt.

Add a new test workflow to test the Meson builds. I was unable to get these tests to pass with Ubuntu 20.04, so they use Ubuntu 22.04.

I'm neither a CMake nor a Meson expert, but the results seem to work for me.

[1] https://mesonbuild.com/

Description

GitHub Issues

[codecov]

Codecov Report

Merging #2530 (d0b0cb1) into devel (4a7cefe) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            devel    #2530   +/-   ##
=======================================
  Coverage   91.56%   91.56%           
=======================================
  Files         183      183           
  Lines        7558     7558           
=======================================
  Hits         6920     6920           
  Misses        638      638           

[mikecrowe]

These changes are being improved based on review comments in mesonbuild/wrapdb#643 . Once that review is complete I'll update this PR.

[horenmar]

Why should the build be part of this project, rather than just a recipe in wrapdb?

[mikecrowe]

Why should the build be part of this project, rather than just a recipe in wrapdb?

I hoped that it would be more likely to stay up to date if it was included in Catch2 itself, just like the BUILD.bazel file is. However, if you're not interested in that then it can stay separate.

[eli-schwartz]

It's indeed more trusted (all content from the original project), easier to use (vs. patching in a secondary source), more likely to remain updated, and works better as a git submodule, or when updating to arbitrary commit checkpoints as the wrapdb will never add support for those.

If, as implied by e.g. the bazel support, the Catch2 project is open to hosting integrations directly, that's the superior solution and the externally patched-in overlay can be dropped from the wrapdb (which may still host a metadata-only record).

[horenmar]

I have two issues with keeping Meson build support in-repo.

1. I don't use Meson, so if it breaks I will have to go and learn new build tool
2. Because it uses explicit file lists, it adds another place to edit when adding another file.

Neither of these are deal breakers, but they are not ideal.

The positive side is that the configuration can be done sanely (unlike Bazel), and that there will be few CI jobs to keep the build functional.

[eli-schwartz]

Speaking with my @mesonbuild core committer hat on, you are more than welcome to ping me and ask for help at any time.

Duplicating file lists across build systems isn't particularly fun, but one possible option is to have a text file with one source filename per line, and read it into each build system. For meson this would be something like:

fs = import('fs')

sources = files(
    fs.read('srclist.txt').split()
)

(Meson will automatically reconfigure if that file list changes, because it's treated as a build definition file.)

[horenmar]

Speaking with my https://github.com/mesonbuild core committer hat on, you are more than welcome to ping me and ask for help at any time.

Very well.

[horenmar]

@mikecrowe Is this ready for review?

[mikecrowe]

@mikecrowe Is this ready for review?

I think so. Would you like me to squash it down to a single commit first?