fluidsynth: Update to 2.2.x

[szhorvat (Szabolcs Horvát)]

fluidsynth 2.2 broke API, which is why MacPorts is still on 2.1.9. Before we can move on to 2.2.x, we need to make sure that all dependent ports are updated to be compatible. This issue serves to coordinate this, and all relevant maintainers are CC'd.

port echo depends:fluidsynth is listed below, along with maintainers and compatibility status:

audacious-plugins          (Ionic, status: ?)
denemo                     (status: ?)
dosbox-x                   (status: ?)
gstreamer1-gst-plugins-bad (status: ?)
libVLC2                    (RJVB, status: ?)
lmms                       (ryandesign, status: ?)
qsynth                     (RJVB, mojca, status: ?)
qtads                      (status: OK for both 2.1 and 2.2)
scummvm                    (status: ?)
scummvm-devel              (status: ?)
VLC2                       (status: ?)

Of these qtads is already compatible with both 2.1.x and 2.2.x. This is how it achieves this:

• ​https://github.com/realnc/qtads/blob/51f99c2d5dc16c4971334e4586f6eeaa8374dcb9/SDL_audiolib/src/DecoderFluidsynth.cpp#L14

Basically, all that seems to be needed is to adapt certain types.

The other ports should be checked and the above table updated with information about what needs to be done to achieve compatibility. VLC2 may be a problem as this old version might no longer be maintained.

References:

• PR that updated to 2.1.9: ​https://github.com/macports/macports-ports/pull/11180

[RJVB (René Bertin)]

If being on v2.1.9 is a defect, then IMHO this ticket should include at least some reasons why beyond the (maybe not so generally accepted) latest-is-greatest principle?

[szhorvat (Szabolcs Horvát)]

There is no urgency to move to newer versions.

However, in my opinion, eventually we won't be able to avoid it. 2.1.9 in fact came out after 2.2.0 as a maintenance release providing compatibility for the 2.1.x API releases with macOS 11. Eventually, a new macOS version is bound to break fluidsynth 2.1.9 as well, and fluidsynth won't be providing bugfix releases for old versions forever.

It just makes sense to start doing the necessary work to be able to move on 2.2.x now, and not leave it until it becomes urgent.

[szhorvat (Szabolcs Horvát)]

A similar reason is that some software/ports that uses fluidsynth is likely to eventually drop support for 2.1.x. So unless those ports are kept at old versions too, something will need to be done.

[kakuhen]

Hello, someone from the dosbox-staging project would like to add their software to MacPorts. Unfortunately, they rely on both the ABI and API of FluidSynth 2.2.x. To remedy the situation with existing ports, I was considering obsoleting fluidsynth in favor of fluidsynth-21, a version locked to 2.1.9, then we can revbump all dependents to use fluidsynth-21, while introducing a fluidsynth-22 port that installs the latest version (and obviously conflicts with fluidsynth-21). What do we think about this approach for the time being?

[RJVB (René Bertin)]

What is the situation with all current dependents, will they build against 2.2.x or are there that may never be updated? In the former case there is no reason to introduce a new port.

In the latter case you'd probably want to make the ports co-installable by using sub-prefixes or suffixes. There are plenty of examples on how to do this. With fluidsynth you can check cmake_admin/DefaultDirs.cmake what options there are to control install locations, possibly patch it if you prefer to use suffixes.

It's not the 1st time this project breaks ABI so it'd be a good idea to make the most future-proof design decisions here.

[szhorvat (Szabolcs Horvát)]

Most likely, the only one that will never be updated is VLC2 (since it's a port explicitly for the old version). Can you patch it to work with the new fluidsynth @RJVB? Should not be hard—see the link in the top post for how Qtads does it.

[RJVB (René Bertin)]

TBH it would be easier to remove midi playback support from VLC2.

[kakuhen]

Ok, I've spent about half an hour searching, and here are some notes.

---

audacious-plugins: NG; many plugins seem horribly out of date (e.g. one of them checks for fluidsynth >= 1.0.8!!!!); 0 requested installs in the past 90 days according to macports website

denemo: NG; probably best to remove port as it has no maintainers, no requested downloads in the past 90 days, and port health is red across the board

dosbox-x: seems ok on 0.84.1 according to AUR; patching configure.ac may be necessary to enable fluidsynth support

gstreamer1-gst-plugins-bad: NG; recommend deleting port; the "Bad plugins" repo has been merged into the gstreamer monorepo and the port as-is is pulling in an abandoned project; moreover, the latest version of gst-bad-plugins does not list fludisynth as a dependency in their meson.build file

libVLC2: NG

lmms: unclear, assuming NG

qsynth: seems ok on 0.6.3+ according to FreeBSD Ports; no patching necessary

qtads: OK according to original post

scuumvm: seems ok on 2.5.0+ according to FreeBSD ports; no patches used for 2.2.x support

scuumvm-devel: seems ok

VLC2: NG

[Ionic (Mihai Moldovan)]

audacious-plugins should be fine with 2.2.x. The ports are outdated, though, when it comes to what's available upstream, so it's possible that the 3.x version of audacious-plugins doesn't immediately support fluidsynth 2.2.x. I don't know when I'll get around to updating them, if ever, but in any case, don't treat it as a blocker.

[kakuhen]

Thanks for the feedback, Ionic.

Anyway, it looks like dosbox-x will be receiving an update soon, but it should still be compatible with newer versions of fluidsynth. In the mean time, I will try testing builds for the following ports with the latest fluidsynth:

• denemo
• lmms
• gstreamer1-gst-plugins-bad

I think VLC2 in the meantime should remove midi playback support until a patch can be sent, or a variant can be made to installer an older fluidsynth.

[RJVB (René Bertin)]

Replying to kakuhen:

I think VLC2 in the meantime should remove midi playback support until a patch can be sent, or a variant can be made to installer an older fluidsynth.

This is simple; whoever will do the fluidsynth upgrade (via direct commit or PR) can

• remove the port:fluidsynth depends_lib entry
• replace --enable-fluidsynth with --disable-fluidsynth

[kakuhen]

OK I have attempting building all three softwares using fluidsynth 2.2.8, here is the summary.

denemo:

• Environment: Mac OS X 10.15.7 (x86_64) with Xcode 12.4 (12D4e)
• MacPorts Context: Compiling in trace mode, allowing binary archives
• Build succeeds and binary seemed functional when testing. The software is compatible with fluidsynth 2.2.8.

lmms

• Environment: Mac OS X 10.15.7 (x86_64) with Xcode 12.4 (12D4e)
• MacPorts Context: Compiling in trace mode, allowing binary archives
• Build fails, but not due to fluidsynth. We are encountering the defect described in #58009. The software is likely compatible with fluidsynth 2.2.8.

gstreamer1-gst-plugins-bad

• Environment: Mac OS X 10.15.7 (x86_64) with Xcode 12.4 (12D4e)
• MacPorts Context: Compiling in trace mode, allowing binary archives
• Build succeeds. The software is compatible with fluidsynth 2.2.8.

If you would like more details on this process, please refer to the Org Mode document I will attach to this ticket. It includes problems I encountered when e.g. building dependents of these ports strictly from source. It also includes snippets of relevant logs to demonstrate programs functioning correctly (or where builds failed).

[kakuhen]

Testing builds of denemo, lmms, and gstreamer1-gst-plugins-bad with fluidsynth 2.2.8 installed.

[kakuhen]

Patch to allow installation of fluidsynth 2.2.8

[mascguy (Christopher Nielsen)]

Updated to 2.2.8, via commit:

​https://github.com/macports/macports-ports/commit/7a1576396019bca3a1c06fb45497d288df9038aa