CMake build fails if we don't set VST3 path or set CLAP_WRAPPER_DOWNLOAD_DEPENDENCIES=TRUE

[mthierman]

Just adding the clap-wrapper to a project will fail if we don't provide a VST3 SDK. Unsure if we should be setting CLAP_WRAPPER_DOWNLOAD_DEPENDENCIES by default or, probably, do nothing.

[cmake] CMake Error at D:/Repos/free-audio/clap-wrapper/cmake/base_sdks.cmake:42 (message):
[cmake]   Unable to detect vst3sdk! Have you set -DVST3_SDK_ROOT=/path/to/sdk or
[cmake]   CLAP_WRAPPER_DOWNLOAD_DEPENDENCIES=TRUE
[cmake] Call Stack (most recent call first):
[cmake]   D:/Repos/free-audio/clap-wrapper/cmake/base_sdks.cmake:115 (search_for_sdk_source)
[cmake]   D:/Repos/free-audio/clap-wrapper/cmake/wrap_vst3.cmake:53 (guarantee_vst3sdk)
[cmake]   D:/Repos/free-audio/clap-wrapper/CMakeLists.txt:102 (target_add_vst3_wrapper)
[cmake] 
[cmake] 
[cmake] -- clap-wrapper: searching for 'vst3sdk' in "D:/Repos/free-audio/clap-wrapper"...
[cmake] -- Configuring incomplete, errors occurred!

[defiantnerd]

The actual intend is that - if you're using the wrapper - you are providing the SDKs, also because of probably licensing issues[*1]. This is because a common scheme is to keep a parent directory structure where a layout like this exists:

MyPlugin1
MyPlugin2
CLAP
VST3SDK
AAXSDK
Common

So you don't need to have a lot of copies of the SDKs in every plugin folder. Therefore the CMake file looks for several typical locations to detect the SDK.

So, I don't think CLAP_WRAPPER_DOWNLOAD_DEPENDENCIES should be default. But perhaps - for each dependency separately - we should change the script to like: if the necessary dependency was not found, download that specific dependency.

[*1] This might not be an issue anymore since the AAX SDK gone GPLv3, too and is at least accessible. So technically it would work, still the user has to check for his license agreement for commercial plugins.

[baconpaul]

I think what we should do is just not depend on the VST3 SDK unless we are building a VST3. Finding out where that dep comes from is the fix to this issue I bet

[defiantnerd]

A flavor argument could be nice: -DCLAP_WRAPPER_FLAVORS="VST3,AUv2" if that is possible.
Alternatively single arguments: -DVST3=1 -DAUv2=1 - but this looks a bit clumsy

[baconpaul]

we can deal with either of those, but they won't much help since both VST3 and AUv2 need quite a lot more info to actually build right?

I do need to return to that gist I started on what the cmake API could be. It could really help if we get that right.

[defiantnerd]

We also could just not build VST3 if the SDK is neither found nor provided.

[baconpaul]

right. the problem is that we are trying to find it even if it isn't requested, somehow.

I think the right semantic is:

If you ask for a VST3 and the SDK resolution fails, fail the cmake
If you don't ask for a VST3, don't look for the SDK, continue the cmake

yeah?

[defiantnerd]

When I started the project, I assumed that users of that library do want to build all for what they have the SDK for. I mean - it doesn't hurt to have an additional flavor of plugin. I still wonder if anyone just wants to build AUv2, but not VST3.

and it should be not covered by dozens of CMAKE -D settings. I really liked the cmake . -Bbuild and it builds everything it finds and gets.

[baconpaul]

So the configuration needs to go somewhere. And it’s not just one string. That’s sort of the thing we are struggling with.

You would want to build an auv2 and not a vst3 if you wanted to build a plugin and not sign the vst3 license agreement. We should definitely support that!