VST3 CMake/Xcode build suddenly stopped working on Mac

General JUCE discussion
1

I’m using CMake with Xcode 16.4 on macOS 15.5 (arm64 Mac).

Up until a few hours ago, everything was working like a charm, I’ve been rebuilding many times today.
But I haven’t deleted my build directory for a while.
I was testing something (changed the macOS deployment target from 13.0 to 10.13), and deleted the build directory to make sure I got a clean build.
Upon running the build again, it suddenly fails the VST3 target, saying “juce_vst3_helper: command not found”…
And taking back all my changes didn’t make a difference either.

Also it doesn’t seem to sign the VST3 correctly anymore? The AAX and AU are correctly signed, but the VST3 is signed ad-hoc due to “code object is not signed at all”. Don’t know if it’s because of juce_vst3_helper failing to run or the other way around?

I was using JUCE 8.0.7, but now I also tried 8.0.8 and develop since I’m in a desperate situation right now (a critical update must be released) – that’s why I’m still awake at almost 4 am…

I can’t understand why it suddenly started failing, and what I have to do to make it work again?

2

If I remove the vst3 helper step with VST3_AUTO_MANIFEST FALSE, then the build succeeds and the vst3 is signed correctly. But without moduleinfo.json, though, obviously… So signing wasn’t the problem.

The auto generated .sh script that tries to run juce_vst3_helper just tries to invoke it with:

juce_vst3_helper -create …

and its location is nowhere in PATH, so it won’t be found.
So if I in Xcode select the VST3 target, go to “Build Phases” and edit the script in the CMake Postbuild Rules to invoke the helper with ./juce_vst3_helper, it starts working.
But this is obviously not how it’s supposed to work :stuck_out_tongue:

It would be interesting to know what it is that goes wrong.

3

Hard to say exactly what is going wrong. My guess would be that for one reason or another the plugin was crashing while being loaded by the vst3 helper and therefore the VST3 target stops building, hence it’s not signed (signing must happen after adding the moduleinfo.json to the binary). Presumably this was ultimately caused by the change in deployment target? However, it’s then surprising that you can manually add the step back in and it works :thinking:. If at some point you can update to the develop branch, the vst3 helper no longer loads the plugin in order to generate the moduleinfo.json file. I understand however that if you need to get a release out of the door this isn’t a practical solution.

1 Like
4

Thank you for the reply!

I also tried on develop, but got the same error. It can’s start juce_vst3_helper at all due to “command not found”.

juce_vst3_helper is built in ../build-desktop/Release/juce_vst3_helper and ad-hoc signed
But the generated post build script for the VST3 target does (simplified):

cd ../build-desktop
juce_vst3_helper -create ...

Which means that ../build_desktlop/Release somehow must be added to PATH somewhere along the line?
Even copying juce_vst3_helper to ../build/desktop won’t help since current dir isn’t a part of PATH either.

I also reverted all my changes to the deployment target to see if that made a difference, but no. I’m not sure if Xcode has auto-updated recently or something like that? But the builds were working perfectly yesterday, and now they don’t :frowning:

5

So .. does this mean that you make your own build directory, say “MYPROJECT/build”, cd into that directory, and then run your “cmake .. -GXCode” to generate the build scaffolding - which includes an XCode generator, so you can then open the .xcodeproj in XCode.app, and do development this way .. ?

Or, do you have some other method of using CMake with XCode?

Just asking, because the method you are using to maintain a CMake/XCode project kind of matters.

If you don’t do the manual ‘mkdir build;cd build;cmake .. -GXcode’ thing, what do you do?

It sounds to me as if you have stale builds, and you need to fully delete the build tree, then regenerate the project from CMake, then do a new rebuild (so that juceaide &etc. is all put in the right place).

But I’m uncertain about this, because .. how do you handle the CMake->XCode step? Seems you need to re-do that.

6

Thanks. I’ve set up a CMakePresets.json that defines a preset called “desktop”:

"configurePresets": [
{
  "name": "desktop",
  "displayName": "Desktop Plugin Build (macOS)",
  "description": "Build VST3, AU, AAX for macOS using Xcode",
  "generator": "Xcode",
  "binaryDir": "../build-desktop",
  "cacheVariables": {
    "CMAKE_SYSTEM_NAME": "Darwin",
    "CMAKE_OSX_ARCHITECTURES": "arm64;x86_64",
    "CMAKE_OSX_DEPLOYMENT_TARGET": "10.13",
    "JUCE_DIR": "../../JUCE 8.0.7"
  }
},
...

I run it from the root of the project tree, where I also have CMakeLists.txt
So the preset will create the build root in parallel to the project tree.
And it has been working perfectly up until now.
Unfortunately I am not very familiar with CMake yet, so I may have messed things up in some other way.

But what I finally decided to do now is to disable VST3_AUTO_MANIFEST in CMakeLists.txt.
Instead I created a template from the last working moduleinfo.json, and put @VERSION@ placeholders in it.
Then I just generate moduleinfo.json from the template on every build and copy it into the VST3 bundle instead of using juce_vst3_helper.
And my installer passed notarization, so I guess it will work out this way!

7

As Anthony mentioned already,
This error is usual due to a crash in the plugin under the vst3 manifest tool or it’s indeed not found.

If it’s a crash you can call the manifest tool with the VST plugin under debugger to catch the issue.

If it’s not found, I guess some path or extra data broke it.

If you use version control… git.
I’d suggest you’ll see when was the last commit that’s working.

You CMake preset got something interesting though and it’s using relative dirs (../build).
I’d suggest checking if that makes any difference.

8

If this problem occurred after deleting the build directory, the solution is to reconstruct the build directory.

But it appears that you may need to dig into your tooling a bit deeper to understand whats going on.

Have you done a ‘manual cmake configuration’? It would look something like this:

  1. cd YourProjectDirectory #wherever the CMakeLists.txt file lives
  2. mkdir build.test
  3. cd build.test
  4. cmake ..
  5. make

.. if this proceeds as expected and builds your project again, then you’ve got a clue as to how to proceed. The CMakePresets.json file is dependent on the existence of a build directory named “../build-desktop” - is this in the right place? Is it named properly? Does it exist at all? How did you create it in the first place? In my list of actions above, you could replace “2./3. mkdir build.test && cd build.test” with “mkdir build-desktop && cd build-destkop && cmake .. && make” to see if you get a successful build again - and also, maybe this is whats needed to get you back on track ..

“juce_vst3_helper: command not found”…

This will get rebuilt when you re-do the cmake configuration and complete a successful build based on detected dependencies.

In your position, I’d try a manual re-configuration of the cmake build directory, try to complete a successful build in that test cmake build directory, and work backwards from there.

9

@ttg has a point about relative paths and CMake, that’s where I would look first.

Whenever I have to use a relative path I use ${CMAKE_SOURCE_DIR}/../path, although you may wish to use ${PROJECT_SOURCE_DIR}/../path

CMAKE_SOURCE_DIR refers to the folder where the top-level CMakeLists.txt is defined.

PROJECT_SOURCE_DIR refers to the folder of the CMakeLists.txt containing the most recent project() command.

1 Like
10

I’m sorry, I realize that I’ve done a lousy job of explaining my issue – It is difficult for me to grasp it myself, let alone putting it into words…

I have a CMake config consisting of a top level CMakeLists.txt (+ some included files) and a CMakePresets.json to set up some different configs.

I have presets for ‘desktop’ (macOS with Xcode generator), ‘windows-debug’ (Ninja build for Windows, Debug config) and ‘windows-release’ (Ninja build for Windows, Release config).

All the presets create “out-of source build directories”, i e build directories that are parallel to the project directory, just to keep “temporary” files separate from my project tree, so “../build-desktop”, “../build-windows-release” etc.

Configuring the build using the preset works just fine, the build directory is created, the Xcode project is generated there and so on. And when I build in Xcode things work mostly fine – The shared code and plugins all compile, are signed etc. The only thing that suddenly started failing was that the VST3 post build script could no longer run juce_vst3_helper (with “command not found”), although it has already done so successfully hundreds of times overl the last week or so.

I still haven’t been able to figure out what caused this or how to make it work again, so at the end my decision was to take juce_vst3_helper out of the equation entirely and replace it with my own CMake-based alternative.

I haven’t made any big recent changes to my CMakeLists.txt, I just changed macOS deployment target in the preset. And changing it back didn’t fix things, so it wasn’t the actual cause of the issue.

So I think I introduced the problem much earlier, but hadn’t noticed since I hadn’t deleted the build directory in a long time, so when I finally did it I probably deleted something that was needed but will no longer be created under my setup. It could even have happened before I put my CMake stuff under version control, because going back to earlier commits doesn’t seem to fix the issue either. But I’m kind of lost since I’m still very unfamiliar with CMake, so I’m just speculating now. :stuck_out_tongue:

Anyway, I just wanted to ask here in case it was a well-known issue, but apparently not, so I have must have done something really weird.

I might try creating a new minimal plugin project to see if I can reproduce the issue in a more controlled environment.