Hi,
Running the JUCE 7.0.12 Projucer here. For some strange reason VST the copy step is failing with XCode because
${TARGET_BUILD_DIR} has the same value as ${destinationPlugin}
Anybody knows where ${TARGET_BUILD_DIR} is being defined or where it might have been corrupted?
The script code line that gives an error is:
ditto "${TARGET_BUILD_DIR}${FULL_PRODUCT_NAME}" "${destinationPlugin}"
Thanks much!
TARGET_BUILD_DIR is a built-in definition: Build settings reference | Apple Developer Documentation
My guess is that destinationPlugin is being set to the wrong value somehow.
What’s the full text of the error message that you see?
Are you modifying the Xcode project at all after saving in the Projucer and before building?
Do you get the same result with a completely blank plugin project? If not, what changes have you made to the jucer project? It might be helpful if you could share the .jucer file with us. You can send it via direct message if you don’t want to share it publicly.
Hi reuk I was able to reproduce this same error with a blank plugin project (selecting AAX, AU, VST3, VST) and enabling the copy step in the Release build. Let me emphasize that this occurs in the last Build Phase of VST(legacy).
I’m using Xcode 15.3 on macOS Sonoma 14.5.
The full error message is:
Running rm -rf "/Users/xxx/Library/Audio/Plug-Ins/VST//NewProject.vst"
Running ditto "//Users/xxx/Library/Audio/Plug-Ins/VST//NewProject.vst" "/Users/xxx/Library/Audio/Plug-Ins/VST//NewProject.vst"
ditto: Cannot get the real path for source '//Users/xxx/Library/Audio/Plug-Ins/VST//NewProject.vst'
Command PhaseScriptExecution failed with a nonzero exit code
If you look at the script the problem seems to be that ${TARGET_BUILD_DIR}${FULL_PRODUCT_NAME} has the same value as ${destinationPlugin}. ${TARGET_BUILD_DIR} should be pointing at the folder where Xcode is outputing the binaries before the copy step but for some reason it isn’t.
I can’t easily test this on Xcode 15.3, but so far I’ve been unable to reproduce this behaviour with a blank VST/VST3/AAX/AU plugin on Xcode 16.0.
(Edit: I’ve also tried Xcode 14.2, and that seems to build without problems too.)
I wonder whether the problem is the use of FULL_PRODUCT_NAME, which doesn’t seem to be documented in the Xcode build settings reference.
It looks like we didn’t use FULL_PRODUCT_NAME prior to this commit. I don’t remember exactly, but I suspect we started using it to match CMake’s output.
Some things you could try:
I’ll also see whether we can avoid using FULL_PRODUCT_NAME - even if that’s not the cause of the problem, it would probably be better to avoid using undocumented features.
I think that maybe WRAPPER_NAME could be used as a drop-in replacement for FULL_PRODUCT_NAME. Could you try doing a find-and-replace in extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_Xcode.h and seeing whether that allows the build to succeed?
If that doesn’t help:
When I click the indicated arrow, Xcode will show the values all of the variables it has set prior to script execution. I’d be interested to know the values it has picked for TARGET_BUILD_DIR, FULL_PRODUCT_NAME, and WRAPPER_NAME.
Hi reuk,
Without modifying anything in the Projucer code those are the variable values before the error:
export TARGET_BUILD_DIR\=//Users/XXX/Library/Audio/Plug-Ins/VST/
export FULL_PRODUCT_NAME\=NewProject.vst
export WRAPPER_NAME\=NewProject.vst
It doesn’t look like replacing FULL_PRODUCT_NAME by WRAPPER_NAME would do anything right?
You can find the full list of variable values here
I’m a bit scared to update my XCode now that everything is working … There aren’t any known issues with JUCE7 and the latest XCode 16.0 right?
Just a little OT hint, this is awesome:
It’s strange that the TARGET_BUILD_DIR is the plugin directory, that’s definitely part of the problem.
I notice in your list of variables that DEPLOYMENT_LOCATION is set to YES, but when I run a local build, this variable is set to NO. The docs for this variable say that it controls whether the built product is built directly to the install location: reference. Perhaps this setting is causing the problem.
It doesn’t look like the Projucer modifies this variable. Do you have an xcconfig file that is overriding DEPLOYMENT_LOCATION? I’m not sure whether there are Xcode global options that can affect this variable. It might be worth checking Xcode’s preferences->locations tab. For me, the Derived Data path is “Relative”, “DerivedData”; and under the “Advanced…” button the Build Location is “Unique”.
But isn’t that correct? From that link you shared:
Identifies the root of the directory hierarchy that contains the product’s files
Isn’t that the plugin folder?
But I’m wondering if maybe the Locations were modified in his Xcode settings? Could changing those from “Default” cause this?
I’m not sure about correct, but it’s definitely not how the Projucer intends for that variable to be expanded. When I run a build locally, TARGET_BUILD_DIR expands to /path/to/project/directory/Builds/MacOSX/build/Debug, i.e. the build directory rather than the install directory. My theory is that the value of TARGET_BUILD_DIR changes based on some configuration option (a global setting or something else) that we don’t expect.
Makes sense. Looking at our scripts, that’s how we treat it as well. Which makes me wonder if the Locations settings in Xcode caused that to change?
