[RFC] meson: replace GNU Make-based build system with Meson

[igoropaniuk]

Replace the existing Makefile-based build system with Meson to improve
build performance, cross-platform support, and maintainability.

Key improvements:

• Build performance: Shared source files (sahara.c, util.c, oscompat.c,
  ux.c, sim.c, io.c) are now compiled once and linked into multiple
  targets instead of being compiled separately for each executable.
  This reduces total compilation units from ~30 to ~20 and speeds up build.

  Full builds tests benchmark results below

  Before (Make):

    $ time make
    ...
    real    0m1.668s
    user    0m1.424s
    sys     0m0.242s
  

  After (Meson):

    $ time bash -c '
    meson setup build
    meson compile -C build'
    ...
    real    0m0.759s
    user    0m0.877s
    sys     0m0.237s
  

• Flexible build directory: Unlike Make which builds in-tree, Meson
  supports out-of-tree builds with custom build directories.

  Example workflows:

    meson setup builddir              # Default debug build
    meson setup build-release --buildtype=release
    meson setup build-asan -Db_sanitize=address
    meson setup build-arm64 --cross-file=aarch64-linux.txt
  

  This enables:

  • Multiple build configurations simultaneously
  • Clean source tree (no .o files polluting git status)
  • Easy comparison between debug/release builds
  • Separate builds for different architectures

• Cross-compilation: Native support for cross-compilation via Meson
  cross-files enables building for multiple architectures without
  requiring separate build runners for each target platform.

  Before (Make): Requires native ARM64 runner in GitHub Actions

    runs-on: ubuntu-24.04-arm  # Dedicated ARM64 hardware
    run: make
  

  After (Meson): Cross-compile from x64 host

    runs-on: ubuntu-24.04  # x64 host
    run: |
      meson setup build-arm64 --cross-file=ci/aarch64-linux.txt
      meson compile -C build-arm64
  

• Automatic dependency tracking: Meson automatically tracks header
  dependencies, eliminating the need for manual dependency declarations
  and preventing missed recompilation on header changes.

  Before (Make): Manual dependency tracking
  util.o: version.h # Must be manually maintained

  After (Meson): Automatic header scanning
  No manual declarations needed
  Changing qdl.h automatically rebuilds all files that include it

  Result: Prevents subtle bugs where changing a header doesn't trigger
  necessary recompilation.

• Platform handling: Windows-specific linking (ws2_32) and platform
  detection are now handled declaratively without shell conditionals.

• Testing integration: Test suite is now integrated into the build system
  with proper dependency tracking and timeout handling.

  Before (Make):
  make tests # Shells out to bash script

  After (Meson):

    meson test -C builddir
    meson test -C builddir --verbose
    meson test -C builddir --wrapper='valgrind --leak-check=full'
  

  Result: Better test output formatting, timeout handling, and ability
  to run tests under valgrind or sanitizers.

• Installation: Standard installation paths and packaging support through
  Meson's built-in install infrastructure.

  Before (Make):
  make install prefix=/usr/local DESTDIR=/tmp/package

  After (Meson):

    meson setup builddir --prefix=/usr/local
    DESTDIR=/tmp/package meson install -C builddir
    # Correctly installs to:
    # - /usr/local/bin/{qdl,qdl-ramdump,ks}
    # - /usr/local/share/man/man1/{qdl.1,qdl-ramdump.1,ks.1}
  

  Result: Better integration with distribution packaging (Debian .deb,
  RPM) and standard FHS paths.

Migration maintains full feature parity with the existing build system:

• All three executables (qdl, qdl-ramdump, ks) build correctly
• Version string generation from git tags
• Optional man page generation
• Support for Linux, macOS, and Windows (MSYS2/MinGW)
• Recreated tests integration via Meson’s test() function,
  including support for script arguments (e.g. --builddir)

Usage:

$ meson setup build
$ meson compile -C build
$ meson test -C build
$ meson compile check -C build

[igoropaniuk]

The changes require some refinement, as I haven't added the checkpatch target yet. Additionally, I need to address an issue with the VERSION option in older versions of Meson (UPDATE: FIXED, old versions of meson require options to be listed in the file meson_options.txt). This is why I initially added the RFC tag, just to gather some initial feedback.

The motivation for this change was a @lumag suggestion in #148

@lumag @andersson FYI

[igoropaniuk]

Should I just keep a minimal Makefile wrapper for all these meson commands, so users accustomed to the make command can continue using it?

[lumag]

Should I just keep a minimal Makefile wrapper for all these meson commands, so users accustomed to the make command can continue using it?

No need to

[igoropaniuk]

Windows build also fails when running in CI; however, it works on my local PC. I probably need more time to investigate and experiment with the CI pipelines here (UPDATE: FIXED)

[igoropaniuk]

@lumag all issues are fixed, added checkpatch targets

[igoropaniuk]

@andersson @lumag If there’s anything else you think should be adjusted or improved, I’m happy to address it - just let me know.

[igoropaniuk]

Updated PR to include manpages build target, which was recently merged

[igoropaniuk]

@andersson @lumag @z3ntu @konradybcio I've updated PR and added detailed justification for transition to Meson in the context of QDL

Let me know what you think

[igoropaniuk]

I understand the concern that switching from Make to Meson might be seen as unnecessary overhead. I tried to outline the motivation and benefits in the commit message, but I’m happy to clarify or expand on any specific points if something is still unclear.

To help with a smooth transition, I can also prepare a compatibility wrapper that preserves the existing make, make install, and make check targets, while using Meson under the hood. That way, existing workflows would continue to work unchanged.

At this point, I’d appreciate your guidance on whether you see a realistic path toward merging this change (possibly with adjustments), or whether you feel this direction is unlikely to be accepted. I want to make sure I’m not spending time iterating on something that doesn’t align with the project’s direction.

[quic-kdybcio]

FWIW I have no concerns