Unified build system (Meson proof of concept)

Is your feature request related to a problem? Please describe.
Having two separate build systems for the command-line program, the cavacore library and other things seems like a situation with room for improvement to me. The current systems also are not very friendly towards distro packagers, and overall a bit fragile and difficult to reason about. Some downstream software that wants to use cavacore currently does so by depending on distro patches.

Describe the solution you'd like
I’m a fan of the Meson build system, so I sat down and wrote a quick proof of concept.
The patch is just under 300 lines and only adds two files. What I have so far:

• Feature toggles for all optional dependencies
• Builds cava executable
• Builds cavacore library, both shared (with soversion set) and static
• Generates pkg-config file for cavacore
• Test suite integrated (both cava test configs and the cavacore test program)
• Compatible with both Meson and Muon (an alternative implementation written in C99)
• Tested with GCC and Clang on Linux (openSUSE Tumbleweed)
• Tested on FreeBSD, macOS and others
• Android build support
• Windows packaging support
• Wrap fallbacks for dependencies that are requested by the configuration but not provided by the build environment

Additional context
Here’s my WIP branch for this issue: master...mia-0:cava:meson

Let me know what you think!

[karlstav]

hi @mia-0,

I have been playing with the idea of using one buildsystem for all. I don't have much experience with meson, but browsing through your patch I think it looks a lot cleaner than both automake and cmake.

One issue is the problem of standardization, we would probably need to keep the automake stuff around for a while either way. I still think we could move forward with meson, but it depends a little on the android support, I could not find any great info about it. At least cmake integrates with android. The android build is not that much used I think, but I am not maintaining cmake AND meson. worst case we could move everything over to cmake and ditch automake.

Anyway this is not something I can use a lot of time on right now, but if you can get a working meson build in I could surely review a PR.

Alright. So, Meson does not have first-class support for Android and Kotlin yet, but it should be possible to get that to work without too much effort and boilerplate code.

The main reason I haven’t done it yet is that I only own mobile devices that run Sailfish OS (which under the hood works like most GNU/Linux platforms), and so have never felt the need to familiarize myself with Android development.

I’ll see if I can tackle it this week. At least cross-compiling C should be super easy, and the Wrap system will take care of bundling dependencies in a clean way. I just don’t know how unnecessarily difficult Google decided to make everything else.

[karlstav]

with #686 I am actually leaning more towards cmake here.

Did you consider the issue of resolving dependencies on windows with meson? For linux this is not an issue as all distros can install all dependencies easily. For windows it's usually a bit more hacky. The nuget thing worked fine for visual studio, but not sure how it works for other IDEs.

Should be technically possible to build fftw3 for android via vcpkg as well. Today this is a bit manual:

https://github.com/karlstav/cava/tree/master/cavandroid#fftw3

Well, I used to maintain a very large (hundreds of dependencies to build) CMake-based toolchain that targeted Windows, so yes I did consider that issue. And, to be frank, I’ve grown to strongly dislike CMake in the process.

For both the Windows and Android case, Meson has the subprojects/Wrap system that manages external dependencies (such as fftw3). It takes care of exactly that. In that sense, it already is a package manager similar to vcpkg and others, except it works independently from any development environment or platform, requires no additional effort to make dependency resolution work, and allows e.g. distro maintainers to prefer system versions or e.g. bundled tarballs for offline reproducible builds.

One project I’ve been involved with, a video game, also uses this system. It targets most operating systems, as well as the Nintendo Switch and WebAssembly, solely through Meson.

In addition, Meson can use CMake to locate dependencies (it does so in a way that is transparent to the user), not just pkg-config and its own logic. It also doesn’t need to use Ninja/Samu, but has backends for Visual Studio and XCode as well.

[karlstav]

yea, everyone hates cmake, especially the people who has been forced to work with it (myself included).

I am willing to give meson a shot, but it must be able to replace CMake AND the visual studio project files completely. That also means replacing the nuget stuff in the visual studio project. I could not find fftw in the list of wrapDB packages, this is a hard dependency any idea on how to solve it? Might be as simple as to download the dll from fftw homepage, we would also need pthreads (maybe i use this one. not sure).

We also need to handle the resource loading thing:

https://github.com/karlstav/cava/blob/master/cava_win/cava/cava.rc

but it looks simple:

https://mesonbuild.com/Windows-module.html

For android I think it can as simple as removing the cmake references from the gradle file:

cava/cavandroid/app/build.gradle.kts

Line 45 in f855c78

cmake {

cava/cavandroid/app/build.gradle.kts

Line 65 in f855c78

cmake {

and after building the libcavacore.so just copy the file as mentioned here:

https://developer.android.com/studio/projects/gradle-external-native-builds#jniLibs

then the libcavacore.so will be loaded as usual here:

cava/cavandroid/app/src/main/java/com/karlstav/cava/MainActivity.kt

Line 296 in f855c78

System.loadLibrary("cavacore")

it will make debugging the native code from the android side a bit more difficult. But I can live with that.

Note that the shared libcavavore.so still needs to contain FFTW as mentioned here:

https://github.com/karlstav/cava/blob/master/cavandroid/README.md#fftw3

We would probably need to keep the automake stuff for some time as most distro packages rely on it today. Not sure how one would go about to "deprecate" a build system.

So the easiest (not best) way to get fftw3 in there is to use its existing CMake-based build system with a wrap subproject. That’s fairly simple, and basically works as-is.

Meson will try its best to make CMake behave, and supplies a cross toolchain file to it. That’s not ideal, though.

Ideally, a proper Wrap should be submitted to WrapDB. That means writing a meson.build file for it. At least for the release tarballs with FFTW3’s already-generated sources, that does not seem too difficult, and I’ll give it a try as soon as I have time. Once it’s there, maintaining it should be easy.

In the meantime, I’ve pushed a commit that does the lazy thing and piggybacks on CMake for now, just to illustrate how this generally works. To enforce its use even when the build environment satisfies the dependency, you can use the --wrap-mode=forcefallback option when running meson setup.

One particular limitation of this is that fftw3 is built as a shared library because CMake treats some options as mere suggestions, like the setting to compile position-independent code. Meson doesn’t know whether it’ll get PIC in the static library output or not, and so will not want to link that to libcavacore.

The modified CMakeLists.txt is only there for convenience: Setting some defaults and allowing it to compile on CMake 4.x, which refuses to configure projects that have a minimum version requirement lower than 3.5.

After that, I’ll look at macOS and Android. The former should be easy enough even when cross-compiling. The latter is a bit of uncharted territory for me, but the Mesa and Chrome OS developers seem to have that figured out.

(By the way, one alternative to FFTW3 is FFmpeg’s implementation in libavutil. That one is much smaller and cleaner, and at least as fast.)

Well. Correction: The CMake wrap does NOT work as-is. Looks like it’s missing the right include paths too, and I’m not sure whose fault it is. Building FFTW3 and cavacore with the Android NDK toolchain does seem to work okay otherwise though. Not surprising, I guess. Will take a look at Kotlin later.

Either way, I’m increasingly determined to remove that pile of hot garbage from as many projects as I can find the energy to. Whole thing was clearly designed by people whose only goal was to replace Microsoft Batch scripts. It has no right to be anywhere near cross-platform software.

Okay, pushed some updates to the branch.

It now includes a wrap for fftw3 that should faithfully reproduce its CMake build system, except it’s all Meson and doesn’t have the Fortran wrapper yet. It looks big, but that’s because I avoided globbing for source files.

This should pretty much just work now. I’ve compiled cavacore with the Android NDK using this setup and encountered no obvious problems. I’m happy.

Well… I kinda got sidetracked into porting fftw’s ENTIRE autotools build system to Meson 😅

That’s a lot of work actually, but I promise I’ll get back to this.

[karlstav]

Haha, no rush, good luck with that.