In the previous CMake change the pkgconfig file was accidentally not installed anymore. Didn't recognized this earlier, because the OBS CI workflow was broken and therefore not running.
by explicitly enabling C language extensions. This will cause the
std=gnu90 to be passed via CMAKE_REQUIRED_FLAGS, making clang know about
the inline keyword rather than failing when querying for the netinet
headers:
/usr/local/lib/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64//sysroot/usr/include/linux/swab.h:39:8: error: unknown type name 'inline'
static inline __attribute__((__const__)) __u32 __fswahw32(__u32 val) {
In my case this is because of issue #985, but there's also the use case of being able to test without OpenMP. For example, to disable it on my system in order to test if the crash had anything to do with OpenMP, I had to manually edit `CMakeLists.txt` each time I wanted to turn it off and on again.
* sanitize_target_dirs(target) removes include and link directories that
do not exist from the given immported target
* generate_pkgconfig_spec() builds fluidsynth.pc taking the private
libraries from a given target dependencies
* FluidSynthConfigVersion.cmake is created with ${VERSION} instead of
${LIB_VERSION_INFO}
* FluidSynthConfig.cmake.in simplified: it doesn't need to include the
version file.
* Simplified BUILD_INTERFACE generator expression as suggested
The build system creates two exported targets:
- The executable FluidSynth::fluidsynth
- The library FluidSynth::libfluidsynth
A downstream project using CMake can find and link the library target
directly with cmake (without needing pkg-config) this way:
~~~
project(sample LANGUAGES C)
find_package ( FluidSynth )
if (FluidSynth_FOUND)
add_executable( sample sample.c )
target_link_libraries ( sample PRIVATE FluidSynth::libfluidsynth )
endif ()
~~~
After installing fluidsynth in a prefix like "$HOME/Fluidsynth3":
cmake -DCNAKE_PREFIX_PATH="$HOME/Fluidsynth3/;..."
Instead installing, the build directory can be used directly, for
instance:
cmake -DFluidSynth_DIR="$HOME/fluidsynth-2.2.2/build/" ...
* FluidSynthConfigVersion.cmake is created with ${VERSION} instead of
${LIB_VERSION_INFO}
* FluidSynthConfig.cmake.in simplified: it doesn't need to include the
version file.
* Simplified BUILD_INTERFACE generator expression as suggested
The build system creates two exported targets:
- The executable FluidSynth::fluidsynth
- The library FluidSynth::libfluidsynth
A downstream project using CMake can find and link the library target
directly with cmake (without needing pkg-config) this way:
~~~
project(sample LANGUAGES C)
find_package ( FluidSynth )
if (FluidSynth_FOUND)
add_executable( sample sample.c )
target_link_libraries ( sample PRIVATE FluidSynth::libfluidsynth )
endif ()
~~~
After installing fluidsynth in a prefix like "$HOME/Fluidsynth3":
cmake -DCNAKE_PREFIX_PATH="$HOME/Fluidsynth3/;..."
Instead installing, the build directory can be used directly, for
instance:
cmake -DFluidSynth_DIR="$HOME/fluidsynth-2.2.2/build/" ...
Previously, cmake only tested for a specific version of libsndfile and then assumed, it has OGG/Vorbis support. However, libsndfile may still be compiled without OGG/Vorbis support. If this is the case, fluidsynth should refuse to load SF3 files. Otherwise the attempt to load SF3 files would fail with a bunch of error messages.
The solution of this PR proposes to lookup the private libs listed in sndfile.pc and see whether it includes "vorbis".
