Using FluidSynth via Meson

[dreamer]

I'll start with saying a big thank you for maintaining FluidSynth - a few months ago we integrated it into DOSBox Staging; recently we improved it via putting it into a separate thread and testing results are great. Thank you so much for making the build process so configurable - it really makes our lives easier. And synth quality is just beautiful :).

For the vast majority of users, we recommend installing the lib available in their OS repository, as FluidSynth 2.x is finally widely available, but there are few edge cases when it does not work (e.g. statically-linked builds on macOS for distributing emulator via .dmg file, builds on Raspberry Pi OS, or standalone builds for Ubuntu 18.04).

In the past, we worked around this by having our own wrapper around your buildsystem (link) - not pretty, but it was the only sensible solution in our old buildsystem. Such problem is not unique to FluidSynth, of course (we have similar wrappers for other libraries as well), but it's really annoying to deal with it.

We solved it for other libraries by replacing our old Autoconf-based buildsystem with Meson (for curious why we decided not to use CMake - link) - and it worked great in general… except again, FluidSynth's CMake-based buildsystem was causing us problems… 😞

To fix it once and for all - I am developing Meson-based wrapper for FluidSynth: mesonbuild/fluidsynth#2 - so far it works great for us; and the solution will be reusable by any other Meson-based project out there 😃.

For the first version it's limited only to the minimum set of FluidSynth features that we use, but hey - if you need more in your project using FluidSynth - send PR (or create a request) in https://github.com/mesonbuild/fluidsynth.

---

OK, with that introduction out of the way, we have an issue with files generated during build time: fluid_conv_tables.c and fluid_rvoice_dsp_tables.c (details), but I wanted to discuss it first before starting work on PR:

• I want to rename these files to have extension .inc.h instead of .c (or something different, just not .c - because these files are not compilable).
• If possible, I would like to backport this change to 2.1.x to trigger 2.1.8 release (unless 2.2.0 is just around the corner and will land in a month or two - in that case I am ok with having it only for >= 2.2.x).
• Once the wrapper will land in Meson WrapDB, are you ok with mentioning it in documentation as another option of using FluidSynth?

BTW, if in some distant future FluidSynth project will decide to move away from CMake - then this Meson wrapper could be a drop-in solution… ;)

[derselbst]

I'll start with saying a big thank you for maintaining FluidSynth - a few months ago we integrated it into DOSBox Staging; recently we improved it via putting it into a separate thread and testing results are great. Thank you so much for making the build process so configurable - it really makes our lives easier. And synth quality is just beautiful :).

Thanks, you're welcome.

To fix it once and for all - I am developing Meson-based wrapper for FluidSynth - so far it works great for us; and the solution will be reusable by any other Meson-based project out there 😃.

To me, this doesn't look like a wrapper, it looks like a meson-replacement-buildsystem. If so, this would be rather fragile. If we make any change to our CMake build system in the future, your "mock" gets out of sync with our buildsystem. It would keep you busy with keeping up with our changes. In worst case, it may continue to work without noticing that something else is broken. Also, your "wrapper" provides no way to execute fluidsynth's unit tests, which I, however, would highly recommend to anybody doing such custom things as you do.

I want to rename these files to have extension .inc.h instead of .c

Ok for me.

If possible, I would like to backport this change to 2.1.x to trigger 2.1.8 release

Ok for me. You're welcome to draft a PR based on the 2.1.x branch.

are you ok with mentioning it in documentation as another option of using FluidSynth?

I'm not sure. It's not maintained by us. So it would be a "yet another custom / unsupported way of building fluidsynth". Is that worth mentioning in our documentation? Because if it didn't work for some reason, people would file a bug, telling me "it's listed in your documentation". And I would tell them "it's not supported, use CMake". If you want, you can ping mawe42, maybe he thinks differently.

BTW, if in some distant future FluidSynth project will decide to move away from CMake

Unlikely. I never liked Python. I don't like Meson's syntax. Admittedly, I haven't given it a serious try, so far. But what I've seen so far (yes, I've read your curious link) hasn't convinced me yet, sry.

[eli-schwartz]

Also, your "wrapper" provides no way to execute fluidsynth's unit tests, which I, however, would highly recommend to anybody doing such custom things as you do.

meson "wrap dependencies" are full projects in their own right and can run tests, which a number of WrapDB projects do. This probably should too!

[mawe42]

I'm not sure. It's not maintained by us. So it would be a "yet another custom / unsupported way of building fluidsynth". Is that worth mentioning in our documentation? Because if it didn't work for some reason, people would file a bug, telling me "it's listed in your documentation". And I would tell them "it's not supported, use CMake". If you want, you can ping mawe42, maybe he thinks differently.

I completely agree with Tom. Having yet another and completely different way to build FluidSynth will not make our life much easier, I think. So I don't think we should officially bless it by linking to it in our documentation. However... we could open up a new section in the Wiki where we link to external bindings for FluidSynth. A bit like a specialised Applications using FluidSynth page, but listing other language bindings (Python, Rust, C++). I could imagine including a link to the Meson FS build there.

BTW, if in some distant future FluidSynth project will decide to move away from CMake

Unlikely. I never liked Python. I don't like Meson's syntax. Admittedly, I haven't given it a serious try, so far. But what I've seen so far (yes, I've read your curious link) hasn't convinced me yet, sry.

I had the exact opposite reaction when skimming through the Meson docs. "Hey, Python... cool!" :-) Made me immediately think about the discussion about the generated files. I imagine having a Python-based build system would make that stuff much easier. But then again... it seems like Meson actively tries to not be Python. I don't know... CMake always feels a little like black magic to me. But as Tom is very fluent in it, is the person putting the most time into the build system and FS in general and is the maintainer, I'm more than happy to simply use what he thinks works best.

[eli-schwartz]

Tests turned out to be completely trivial to add: mesonbuild/fluidsynth@8e1ad41

[dreamer]

To me, this doesn't look like a wrapper, it looks like a meson-replacement-buildsystem.

You're correct - it is :) glib and gthreads both use Meson already, so it was easier for me to rewrite the buildsystem in Meson rather then deal with CMake in the middle. Over last few months we had several random CI failures (mostly on macOS), and so far it seems like with Meson we can deal with it efficiently (that is: "it just works").

It will be faster for me to spend some time every few months updating this solution to the new FluidSynth release rather than dealing with random build failures on macOS every two weeks.

So far it was rather easy - the only problematic part was generator of those two .c files, and only because I lacked some Meson knowledge.

To me, this doesn't look like a wrapper, it looks like a meson-replacement-buildsystem. If so, this would be rather fragile. If we make any change to our CMake build system in the future, your "mock" gets out of sync with our buildsystem. It would keep you busy with keeping up with our changes. In worst case, it may continue to work without noticing that something else is broken. Also, your "wrapper" provides no way to execute fluidsynth's unit tests, which I, however, would highly recommend to anybody doing such custom things as you do.

I am going to update Meson-based buildsystem after you will create a stable release - based on my experience so far, this shouldn't be that much work :) I'm going to deal only with library, so that makes the task a bit easier as well.

Thank you for suggesting that we should build unit tests as well, as @eli-schwartz mentioned - this turned out to be easy, and I discovered 2 small issues in the wrapper in the process 😄. So far all tests pass (initially I pointed TEST_SOUNDFONT to Fluid_R3, and tests were failing - so they are not false positives either).

I want to rename these files to have extension .inc.h instead of .c

Ok for me.

If possible, I would like to backport this change to 2.1.x to trigger 2.1.8 release

Ok for me. You're welcome to draft a PR based on the 2.1.x branch.

are you ok with mentioning it in documentation as another option of using FluidSynth?

I'm not sure. (…)

That works for me :) I'll start working on PRs. I guess most developers using Meson will find the wrap via WrapDB anyway - if someone will come asking questions about it, then redirect people to https://github.com/mesonbuild/fluidsynth - I'll be happy to help.

However... we could open up a new section in the Wiki where we link to external bindings for FluidSynth. A bit like a specialised Applications using FluidSynth page, but listing other language bindings (Python, Rust, C++). I could imagine including a link to the Meson FS build there.

Oh, that would be nice! Wiki seems like an appropriate place.

But then again... it seems like Meson actively tries to not be Python. I don't know... CMake always feels a little like black magic to me. But as Tom is very fluent in it, is the person putting the most time into the build system and FS in general and is the maintainer, I'm more than happy to simply use what he thinks works best.

Meson is implemented in python (which comes with some benefits) - it's not python (Meson language is different), but it shares some similarities (e.g. "batteries included" philosophy). Those two generated .c files are good example - in CMake you need to undefine/define variables and make workarounds to assure the program works when cross-compiling. In meson, the solution was literally a single line: native : true in executable function. Tests were also easy to define, as Meson natively supports various unit tests using popular conventions, frameworks, harnesses, etc. We don't need to worry about keeping in sync with FluidSynth config.h, as Meson supports CMake's #cmakedefine syntax, etc, etc…