Issues building and configuring SDK 3.6.9


We’ve been selling a suite of plugins that so far has been based on the VST SDK version 3.6.6. Now we’ve decided to update to the latest version of the SDK, version 3.6.9. The change of the SDK to using cmake instad of pre-configured Xcode projects is giving us a number of problems.

I’ll just list the main issues here in the hope that someone might suggest workarounds or an easier workflow:

  1. It seems certain cmake options are broken.

For instance, adding


ends in:

CMake Error at cmake/modules/AddVST3Library.cmake:85 (add_library):
Cannot find source file:


2. vst2wrapper is not included in the sdk target by default.

We need vst2 support. It may be a deliberate choice to not include the v2 wrapper by default, but the reality is that we won’t be building vst3 plugins until Ableton Live X will add support for them. Until that day arrives, vst2 support should be part of the sdk target in the generated Xcode project.

At the moment there is not even a cmake option to enable this. We needed to modify the sdk CMakefile to accomplish this. This is not ideal.

3. Hard paths in the Xcode project.

The Xcode project that is generated by cmake is full of hard paths into the file system that cmake was run on. The Xcode project is therefore not portable, which is problematic since we will add the VST SDK to our code repository, and we can’t simply run cmake as a pre-building step because of point 2. The configured Xcode project in the 2.6.6 SDK did not have this problem.

(Also, the xcode project no longer uses .xcconfig files to share build settings between targets, so optimizing the project to our liking takes more time)

All in all, generating and configuring the sdk using cmake is a fairly problematic experience for us. Out of the box it misses vst2 support and we can’t simply and easily optimize the Xcode project for our use and add it to our code repository. If memory serves, this was much easier with the 2.6.6 release.

We’d be grateful for any good workarounds for these issues.


sorry I don’t have an immediate answer for you, but we will discuss this here on how to handle this use case.
Just one more question to get it right. Are you building only for macOS, or do you don’t have any issue with this change on Windows ?


Hi Arne,

Thanks for the quick reply!

This feedback is just about building for macOS. We do have Windows versions or our VSTs too, but building those is the task of a different team (who will use the same, shared repo containing the vst.sdk).

Another point I want to add: the (intermediate) build products end up in the folder where cmake creates the Xcode project, not in the Xcode default build location. This means that it’s more likely to end up in automatic (TimeMachine) backups. There are probably a few other things that could be optimized for a better experience.


I don’t know if it can help but I wrote a blog post series about my experience (struggling) to build VST plugins (2 and 3) and also found some issues and workarounds… you can check it out here: It is targeting 3.6.9

The good news is that in the end I am able to build a plugin that is both 2.4 and 3 and it’s open source so you can see what I have done:


Thanks Yan,

I’ll have a look at it for inspiration.