[Feature]: meson.build support

[mochaaP]

Problem Description

I'd like to add this library to https://meson.build's wrapdb.

Proposed Solution

• Maintaining meson build files in this repository.
• Add CI build tests for meson.

🚀 Compiler Explorer Example (Optional)

No response

Alternatives Considered

Maintaining build files in wrapdb as patches. This can work but will need a manual sync for every version.

Feature Category

Build System

Example Usage

meson wrap install mp-units

executable('user', 'main.cc', dependency: dependency('mp-units'))

meson setup builddir && meson compile -C builddir

Priority

Blocking my adoption

Implementation Ideas

I'm currently writing an implementation; it would be nice if it could be accepted upstream.

Additional Context

meson have many features built in that are currently implemented as CMake scripts.

• clang-format && clang-tidy support (auto-detecting configuration files and adding build targets for linting and autofixes)
• ccache / sccache support
• libc++ detection
• c++ modules (soon OOTB, requires testing on more different environment setups)

if you want some nice additions for making development more enjoyable, please let me know, and I will try to implement them in meson core :)

Checklist

• I have searched existing issues to avoid duplicates
• I have read the project documentation
• This feature aligns with the project's goals

[mpusz]

Hi @mochaaP

Thank you for your interest in contributing to mp-units. It’s always great to see the community wanting to bring the library to more developers and build ecosystems.

Before we dive into your PR, I want to be transparent about my position as the maintainer. While I appreciate the benefits Meson brings to certain workflows, adding support for a second build system gives me some pause for a few reasons:

• Source of Truth: CMake is the de-facto standard in the C++ community and remains the primary "Source of Truth" for this project.

• Maintenance Burden: My main concern is the duplication of logic (target definitions, project options, compiler flags). Every time I add a feature or change a requirement in CMake, I would need to mirror that in Meson—a tool I don't use daily and don't have the bandwidth to master.

• Long-term Stability: I’m worried about the "bitrot" of these files. If a change is made to the library that breaks the Meson build, I likely won't know how to fix it myself, leading to a broken experience for Meson users.

That said, I am open to merging this support under a few conditions:

1. Mandatory CI: The PR must include a robust CI configuration (GitHub Actions) that builds and tests the library using Meson across our supported toolchains. This is the only way I can ensure the Meson build stays healthy without me manually checking it.

2. Community-Driven Maintenance: By adding these files, the community (and you specifically) would need to take "ownership" of them. If the Meson build breaks in the future, it will be up to Meson users to provide the fixes.

3. Minimal Noise: We should ensure the meson.build files are as lean as possible to avoid cluttering the repository.

If you are comfortable with providing the CI infrastructure and understanding that CMake will always take precedence in the development workflow, I’m happy to review the PR!

Best regards,

Mat

[mochaaP]

Thank you, I will start working on it and try to keep feature parity with CMake. If you add something to CMake in the future just tag me and I will resolve it.