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

[igoropaniuk]

Replaces the legacy GNU Make–based build system with a modern, cross-platform Meson.

• Added meson.build files defining all three executables:
  • qdl
  • qdl-ramdump
  • ks
• Replicated original Makefile logic:
  • Source file lists and dependency linking (libusb-1.0, libxml-2.0)
  • Platform-specific link options (-lws2_32 on Windows)
  • Automatic version.h generation using git describe, with fallback to $VERSION or "unknown-version"
  • Recreated tests integration via Meson’s test() function, including support for script arguments (e.g. --builddir)

To build QDL and run tests:

$ meson setup build; meson compile -C build; meson test -C build
The Meson build system
Version: 1.3.2
Source dir: /home/xdev/foundries.io/reps/qdl.git
Build dir: /home/xdev/foundries.io/reps/qdl.git/build
Build type: native build
Project name: qdl
Project version: undefined
C compiler for the host machine: ccache cc (gcc 13.3.0 "cc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0")
C linker for the host machine: cc ld.bfd 2.42
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
Run-time dependency libusb-1.0 found: YES 1.0.27
Run-time dependency libxml-2.0 found: YES 2.9.14
Configuring version.h using configuration
Program bash found: YES (/usr/bin/bash)
Build targets in project: 10

Found ninja-1.11.1 at /usr/bin/ninja
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/xdev/foundries.io/reps/qdl.git/build
ninja: Entering directory `/home/xdev/foundries.io/reps/qdl.git/build'
[36/36] Generating ks-manpage with a custom command
ninja: Entering directory `/home/xdev/foundries.io/reps/qdl.git/build'
ninja: no work to do.
1/1 run_tests.sh        OK              5.66s

Ok:                 1   
Expected Fail:      0   
Fail:               0   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0   

[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

[andersson]

Why? What problem does switching to meson solve?

[igoropaniuk]

@andersson The motivation for this change originated from another PR, #148, and suggestions there to explore better solutions like Meson

[z3ntu]

Also makes it possible to easily build a static qdl with LDFLAGS="-static" meson setup builddir --prefer-static && meson compile -C builddir

[andersson]

I suppose the proposed cleanup of build output, provided by #148, was nice. I don't see the benefit of building debug and release builds in that fashion. I presume meson would handle that better for us - without having "make all" build the project twice.

But I'm not convinced about the benefits. Perhaps I just don't know the capabilities of meson well enough? But are we just trading some clutter in the source directory for the addition of two new dependencies?

@z3ntu tell me more, when do you use this?

Regarding the change itself, it should contain the motivation for the change. It should be possible for someone to look back at this PR, or the git log, and understand why we did choose to completely replace the build system.

[igoropaniuk]

@andersson Just some of my observations.:

1. The syntax is simpler and high-level (so we need fewer instructions to do the same compared to make), and it's declarative (we give instructions about what to build, and it knows how to build)
2. Much more advanced dependency management (I know we have only two now, but nevertheless)
3. Clear, user-friendly error messages (with colors, context, and hints).
4. More flexible, reusable configuration management built in - no need to hack together shell conditionals in Makefiles.
5. Built-in native support for unit-tests (with a test() statement), so we basically can simplify scripts in the test subdirectory

Given that the project is rapidly growing, meson will help us in future to automate what makes us micromanage
(for example, like tweaks I have in #148)

[igoropaniuk]

Rebased onto the latest master

[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