[Bug]: missing CMake command to enable linking against (system) libraries

[umlaeute]

Detailed steps on how to reproduce the bug

With CMake-based projects, the typical way to enable/disable support for e.g. FLAC, is to add a JUCE_USE_FLAC=1 (which is the default), resp JUCE_USE_FLAC=0 define via target_compile_definitions(), e.g. https://github.com/juce-framework/JUCE/blob/965d0ca4be178c4a0000b116d460e15c30311992/extras/AudioPluginHost/CMakeLists.txt#L49-L63

This (probably) works nicely, if the entire libflac is automagically included via preprocessors directives in the the juce-modules.

Unfortunately, it doesn't help if you are trying to use a system provided libflac, as in this case, the linker-flags are missing.

This (using system-provided libraries, rather than vendoring whatever you need) is required e.g. by the Debian-packaged JUCE.

Rather than adding these linker flags manually in my Cmake project, I'd like to leave that to the JUCE installation (so I can use the same project on Windows (using vendored libraries) and Debian (using system libraries), leaving that as an implementation detail on the JUCE side.

What is the expected behaviour?

So rather than having target_compile_definitions(MyProject PRIVATE JUCE_USE_FLAC=0 JUCE_USE_OGGVORBIS=1); i would like to suggest to add a JUCE-specific Cmake command to enable/disable these libraries.

I'm not much of a Cmake expert, but I imaging something like:

juce_use_libraries(MyProject curl oggvorbis)

which would then automatically add -DJUCE_USE_CURL=1 -DJUCE_USE_OGGVORBIS=1 -DJUCE_USE_FLAC=0 ... to my compiler flags. If I use a devendored JUCE-installation (such as in Debian, or arch Linux), it would also add -lcurl -logg -lvorbis to the linker-flags.

It's up to the distribution maintainers to implement such specific library additions, but JUCE would provide a common interface (the juce_use_libraries Cmake command).

Operating systems

Linux

What versions of the operating systems?

nn

Architectures

x86_64

Stacktrace

No response

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

I have not tested against the develop branch

Code of Conduct

• [X] I agree to follow the Code of Conduct

[umlaeute]

sidenote: afaik there's no way to check whether the user added something like JUCE_USE_OGGVORBIS=1 to their build flags from within the JUCE Cmake snippets. that's why i was asking for a specific Cmake command.

[dvzrv]

I'd also be very much interested in a feature like this (I am packaging JUCE for Arch Linux), as it allows downstream distributions to have packages relying on JUCE to link against system libraries and be rebuilt in one operation in case there are changes to the libraries.

[tpoole]

I'm afraid that the JUCE team does not consider this a bug, even if this is going against the requirements of various Linux distributions.

JUCE does not support using system provided libraries like libflac. In cases like this we bundle a specific version of the dependency with the rest of the JUCE framework. Each specific version is tested and verified as working with the corresponding version of JUCE, and it may also include bug fixes and tweaks to the corresponding source code to address any issues we have encountered. We do not want JUCE to be used with unmodified, untested, versions of dependent libraries, and dedicating developer time to making this possible is not a good use of our resources.

[umlaeute]

while i understand, that you do not want to support "unmodified, untested, versions of dependent libraries", I still think that a Cmake command to enable specific features (without having to worry about whether this requires whatever preprocessor define) is a bonus from a developer perspective.