Allow building the library only, without tools and sound devices support

[Wohlstand]

Currently, both CMake and Autotools builder do always produce builds of both library and executable, and I didn't find any settings to disable build of executable, audio output and all related configure checks. For several purposes (such as making portable applications, games, mobile applications, etc.), it's possible to take a copy of the repository and build the library together with the main application in the same package. In such cases, included demo/helper tools were usually disabled as they are totally unneeded for application use, and there is no reason to build them. There is around the stripped fork of FluidSynth called FluidLite, but it doesn't seem to make any major progress for a while.

EDIT: clarified the paragraph above

And I think, would be cool to allow build scripts to build the:

• library only (don't build executable)
• for some other cases, disable some parts of the library such as the built-in MIDI sequencer or some other, keeping real-time MIDI API only
• disable audio output devices support, keep only raw output PCM/float calls to let developer handle all audio output by theme selves.
• etc.

What do you think?

[derselbst]

Currently, both CMake and Autotools builders do always produce builds of both library and tools, and I didn't find any settings to disable tools and audio output

Fluidsynth doesn't have an "Autotools builder". The one and only build system is CMake. And this already provides various options to compile a hilghly customized, stripped down version of fluidsynth. I don't know, to which "tools" you are referring. By default, fluidsynth's library and the executable are compiled. Demos and unit tests are only compiled when explicitly asked for. Hence, it is not really clear to me what you're asking for particularly.

And I think, would be cool to allow build scripts to build the:

• library only (don't build tools)

make libfluidsynth and the executable won't be compiled.

• for some other cases, disable some parts of the library such as the built-in MIDI sequencer or some other, keeping real-time MIDI API only

The MIDI sequencer is an integral part of fluidsynth that has no special dependencies. Stripping it away would mean to make severe parts of fluidsynth API inoperateable. This won't happen.

• disable audio output devices support, keep only raw output PCM/float calls to let developer handle all audio output by theme selves.

See the enable-xxx cmake options.

• etc.

?

[derselbst]

But I would have one option that disables all of them at once.

This flag would be redundant to the other existing flags. We had such a redundant flag in the past "enable-debug" which was conflicting with "CMAKE_BUILD_TYPE". We removed it in the end.

Also, this flag should handle any future additions that will be done in the future

I don't like functionality that only serves for "lazy purposes", sry. If someone wants a lightweight build, I would expect him to take 10 minutes and see how this can be achieved. Also, if anything new would be added, you would have to actively install the necessary dependency libraries and headers to make it work. And something "new" is only added upon minor version bumps, which is easy to recognize as well. So sorry, I don't really like this idea.

However, I have no strong opinion on adding yet another flag that would disable compiling the executable. I don't see a real benefit in doing so, but it wouldn't hurt either.

[Wohlstand]

However, I have no strong opinion on adding yet another flag that would disable compiling the executable. I don't see a real benefit in doing so, but it wouldn't hurt either.

After years I found a moment to reply: the true benifit is that when the wohle project of FluidSynth gets embedded into another one as a kind of CMake sub-directory or ExternalProject, and when project uses library itself and executables of FluidSynth itself are totally unneeded. And of course, all the checks for OS specific interfaces such as DirectSound, CoreAudio, ALSA, etc. are totally redundant in a scope of project where this thing got been embedded. And executables built by FluitSynth are also redundant. And even more, if project targets to foreign architecture (i.e. the cross compilation is performed), these executables even more redundant. The major example - Android. The library gets embedded into project as statically-linked thing, and all the checks are out of scope of library itself (not executables) are just delaying the configure step so much.

So, in short words, the true benifit to have flags to completely strip down everything than the library itself and platform specific audio output interfaces:

• Speed-up the build when library is used as embedded project (no redundant checks)
• Don't produce any other files than library itself (these files are just useless here)

So, it would be have multiple CMake flags:

• One or multiple CMake-wide flags to completely disable any OS specific functionality like audio output or OS-wide MIDI-IN interfaces handling (no configure checks, no modules enabled) to keep library mostly platform-independent. So, such library contains nothing than public functions are used to send MIDI commands directly or just load a MIDI file to play it with built-in MIDI sequencer, and retrive generated PCM buffer that software will use for its internal needs.
• A set of related CMake lags per every executable that supposed to be build.
• All the checks are required for only that executable should be wrapped into the flag that covers THAT executable.

[derselbst]

One or multiple CMake-wide flags to completely disable any OS specific functionality like audio output or OS-wide MIDI-IN interfaces handling

"multiple CMake flags" - That's exactly what we already have. Just set them all to OFF in your external cmake project. The "platform-independent" part is also inapplicable. Fluidsynth is written in C / C++ - it will never become "platform-independent"... not even "mostly". You're a C++ guy, you should know that.

A set of related CMake lags per every executable that supposed to be build.

Again: that's what targets are for: make libfluidsynth

The major example - Android. The library gets embedded into project as statically-linked thing

I hope your project is (L)GPL licensed then, otherwise it would be a license infringement.

[Wohlstand]

multiple CMake flags" - That's exactly what we already have. Just set them all to OFF

That's awesome!

Fluidsynth is written in C / C++ - it will never become "platform-independent"

I meant as "platform-dependent" the set of explicit operating-system speccific APIs like CoreAudio, WinMM, DirectSound, ALSA, PulseAudio, etc. I.e. avoiding these APIs just keeing pure C/C++ standard libraries should guarantee the project will build on every known and unknown platforms, including baremetal targets. Just keep configure for the most significant parts like non-standard functions, workarounds, endianess, etc.

Again: that's what targets are for: make libfluidsynth

That is suitable if just build thing as a local one, but it is not suitable in a scope of ExternalProject or subdirectory, it will always stick on all, and of course, all the dependent configure steps WILL run. But my goal is avoid them. Especially if project suppose to use different build system.

I hope your project is (L)GPL licensed then, otherwise it would be a license infringement.

Don't worry about that, my projects are GPL.

[derselbst]

That is suitable if just build thing as a local one, but it is not suitable in a scope of ExternalProject or subdirectory, it will always stick on all, and of course, all the dependent configure steps WILL run. But my goal is avoid them.

Ok, if you insist this is necessary, the solution could be to add a new CMake option which effectively EXCLUDE_FROM_ALL the fluidsynth executable (and potentially other executables in the future) and only keeps libfluidsynth to be run by all. This approach would still allow those targets to be built upon request (might be useful for testing purposes, or in case other targets depend on those targets).

@carlo-bramini You recently had a similar request in #1632, what's your opinion about that proposal?

[pedrolcl]

The problem with FluidLite is that frequently falls behind FluidSynth, because the maintenance of that project is really slow. On the other hand, FluidSynth does not provide a way to strip down the library, for instance the sequencer, or the shell, in addition to individual MIDI/Audio drivers. This is what it makes FluidLite appalling to some projects that only want a synthesizer engine without any extra functionality.

[carlo-bramini]

Well, I'm maintaning/upgrading several packages for CYGWIN that you can find here:

https://github.com/carlo-bramini/packages-cygwin

Here you can also find the packages with fluidsynth, updated to the latest stable version.
Together with the build for CYGWIN, you can also find the packages for the MinGW-w64 cross compilers.
Actually, those packages also include fluidsynth.exe but since they should not be there because they are made for the cross compilers.
Perhaps, it would be useful to avoid it, because it would conflict with the same executable for CYGWIN, if the sysroot of the cross compilers are added to the patch.
In my opinion, at the time of writing a possible solution is to modify my scripts for deleting this executable before assembling the package. Here, an option for disabling the creation of the command line tool would be helpful, but not critical.

However, a problem could rise if the command line utility could not be created for other reasons.
An example is the package of Fluidsynth for Windows CE, because it doesn't support console applications at all, but only windowed.
Here, creating fluidsynth.exe just fails because it is not possible.

The suggestion you gave to me into #1632 allows to build the library.
Unfortunately, I had troubles when doing the install, because this command doesn't work:

cmake --install . --prefix ${DEST} --component libfluidsynth

So, I stopped here, because it needed less time to patch CMakeLists.txt and avoid completely the creation of the command line utility.
I hope that you will find this information useful.

[pedrolcl]

it would conflict with the same executable for CYGWIN, if the sysroot of the cross compilers are added to the path.
Here, an option for disabling the creation of the command line tool would be helpful, but not critical.

Yes, that is a valid argument in favor of an option for building the CLI program or not.

However, a problem could rise if the command line utility could not be created for other reasons. An example is the package of Fluidsynth for Windows CE, because it doesn't support console applications at all, but only windowed. Here, creating fluidsynth.exe just fails because it is not possible.

This could be handled by the CMake script:

if (CMAKE_SYSTEM_NAME MATCHES "WindowsCE") ...

Or could be managed using the mentioned option.

The suggestion you gave to me into #1632 allows to build the library. Unfortunately, I had troubles when doing the install, because this command doesn't work:

cmake --install . --prefix ${DEST} --component libfluidsynth

This is an entirely different approach. For this to work, we need to define the component names in the CMake script, when using the install() macro. But component names are not the same as target names. An example of meaningful and common component names could be:

• Runtime
• Development
• Tool
• Documentation

Where Runtime includes the shared library/DLL only, Development includes the headers and the import library (requires Runtime), Tool includes the CLI program (requires Runtime), and Documentation includes the man page, text files, etc...

These are the same groups packagers already do for Linux distros, for instance:

• libfluidsynth3 (Runtime component)
• libfluidsynth3-devel (Development component)
• fluidsynth (Tool + Documentation components)

So, this way we may build all components, but only install a predefined selection group. These groups is also recognized by some CPack installers generators, and some Windows installers like NSIS and Wix, allowing the users of the installers to choose what components to install.

A few additional documents talking about this, just in case this comment is turned into an issue and I create a PR:

• Mastering CMake: Installing targets
• Install command: targets
• CMake(1): Install a project
• CPackComponents module

[derselbst]

I was hoping for @Wohlstand to provide some feedback. Yet, here are my two cents: As always I'd like to avoid introducing even more custom CMake flags and options that complicate usage and add complexity to the behavior of the build system. The component-based approach looks particularly suited for the problem addressed here. I'm all in favor and would welcome a PR.

[carlo-bramini]

However, CMakeLists.txt already provides these options:

enable-alsa
enable-aufile
enable-coreaudio
enable-coreamidi
enable-dart
enable-dsound
enable-jack
enable-kai
enable-midishare
enable-oboe
enable-opensles
enable-oss
enable-pipewire
enable-portaudio
enable-pulseaudio
enable-sdl3
enable-wasapi
enable-waveout
enable-winmidi

So, you can already disable all drivers if you don't need them.