Open yurivict opened 1 month ago
You should be able to set surge juce path as a cmake variable if you want an alternate juce
tomorrow I’m going to update our branch to juce 7.0.12 which may resolve this problem.
juce 8.0.0 also builds fine.
Yeah thanks! We are holding off on the 8 upgrade due to some changes in windows graphics - too big a jump for a point release. But 1.3.3 later this summer (and soon the nightky later today) will be 7.0.12.
The change in Windows graphics is actually a welcome one - things look a lot better via D2D renderer. The license change is probably a more contentious point.
1) the license change ended up fine once it was all resolved. That was all cleared up on the juce forum basically 2) the windows graphics change is welcome if it works. but there's a bunch of bug reports still kicking around the juce forum.
So basically "yes direct2d is way better except for the bugs"
I just pushed a nightky with a juce that is 7.0.12 plus patches. That or using an alternate juce should work for you. Please do let us know! Thanks
@baconpaul
SURGE_JUCE_PATH
assumes the source tree being present.
But JUCE has the 'install' target, and is discoverable with find_package(JUCE)
.
Surge should be using find_package(JUCE)
first before using the bundled JUCE.
Well we absolutely shouldn't use it before the bundled juce. Our juce has fixes which are important to several of our users (but not on FreeBSD).
But sure I suppose a person could modify the cmake to do a find package and access that mode through another option! I'd be happy to merge that.
Anyway please do let us know if the package builds - if so I’ll close this issue and open a fresh fr for the find package thing
Version 1.3.2 with the JUCE-7.0.12 patch from the PR fails to build:
CMake Error at src/cmake/lib.cmake:13 (add_dependencies):
The dependency target "surge-fx_VST3" of target "surge-fx_Packaged" does
not exist.
Call Stack (most recent call first):
src/surge-fx/CMakeLists.txt:94 (surge_juce_package)
CMake Error at src/cmake/lib.cmake:13 (add_dependencies):
The dependency target "surge-xt_VST3" of target "surge-xt_Packaged" does
not exist.
Call Stack (most recent call first):
src/surge-xt/CMakeLists.txt:255 (surge_juce_package)
Can you let me know the flags you are using? What’s your build script
looks like you are not building the vst3 but are building the package which seems to want to include it so that may be our error. Some more details would help
It passed this point when I added SURGE_SKIP_VST3=ON.
All cmake arguments: -DCMAKE_C_COMPILER:STRING="cc" -DCMAKE_CXX_COMPILER:STRING="c++" -DCMAKE_C_FLAGS:STRING="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing " -DCMAKE_C_FLAGS_DEBUG:STRING="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing " -DCMAKE_C_FLAGS_RELEASE:STRING="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -DNDEBUG" -DCMAKE_CXX_FLAGS:STRING="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -I/usr/local/include/midifile -DPLUGIN_API="" -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -Dstrnicmp16=strncasecmp -isystem /usr/local/include " -DCMAKE_CXX_FLAGS_DEBUG:STRING="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -I/usr/local/include/midifile -DPLUGIN_API="" -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -Dstrnicmp16=strncasecmp -isystem /usr/local/include " -DCMAKE_CXX_FLAGS_RELEASE:STRING="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -I/usr/local/include/midifile -DPLUGIN_API="" -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -Dstrnicmp16=strncasecmp -isystem /usr/local/include -DNDEBUG" -DCMAKE_EXE_LINKER_FLAGS:STRING=" -lmidifile -fstack-protector-strong -L/usr/local/lib " -DCMAKE_MODULE_LINKER_FLAGS:STRING=" -lmidifile -fstack-protector-strong -L/usr/local/lib " -DCMAKE_SHARED_LINKER_FLAGS:STRING=" -lmidifile -fstack-protector-strong -L/usr/local/lib " -DCMAKE_INSTALL_PREFIX:PATH="/usr/local" -DCMAKE_AUTOGEN_PARALLEL:STRING="7" -DCMAKE_BUILD_TYPE:STRING="Release" -DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DFETCHCONTENT_FULLY_DISCONNECTED:BOOL=ON -DSURGE_SKIP_VST3:BOOL=ON -DJUCE_PLUGINHOST_VST3:BOOL=OFF -DJUCE_PLUGINHOST_VST:BOOL=OFF -GNinja -DPython_ADDITIONAL_VERSIONS=3.11 -DPython_EXECUTABLE:FILEPATH="/usr/local/bin/python3.11" -DPython3_EXECUTABLE:FILEPATH="/usr/local/bin/python3.11" -DBOOST_PYTHON_SUFFIX:STRING=311
So did it build with SKIP_VST3=ON?
Those are a lot of flags. Some (like NDEBUG in a prod build) are ones which will make the synth behave quite badly. There's quite a few spots where we assume debug isn't on in a release build idiomatically and setting that will replace a user-facing error with a core.
Also the stricmp ones should no be longer needed. Those are remnants from the pre-jute surge.
And we no longer use libmidifile (it's removed as ausbmodule) so your code to use your system version instead of our bundled version is no longer needed.
Also why -O2 as opposed to -O3 -fast-math?
but if your users are happy with the build from that setting I'm fine. Just offering some observations.
So did it build with SKIP_VST3=ON?
Yes, it builds fine with SKIP_VST3=ON. Something is wrong with the VST3 support.
Those are a lot of flags. Some (like NDEBUG in a prod build) are ones which will make the synth behave quite badly. There's quite a few spots where we assume debug isn't on in a release build idiomatically and setting that will replace a user-facing error with a core.
NDEBUG means no asserts. This improves performance in the release build. I think that you've probably misread it.
Also the stricmp ones should no be longer needed. Those are remnants from the pre-jute surge.
This is a generic option that is added by ports framework. I don't think that it realistically hurts anything.
And we no longer use libmidifile (it's removed as ausbmodule) so your code to use your system version instead of our bundled version is no longer needed.
I removed this dependency.
Also why -O2 as opposed to -O3 -fast-math?
I adjusted the flags to be -O3 -fast-math in the release build.
Thank you for your suggestions!
NDEBUG means no asserts. This improves performance in the release build. I think that you've probably misread it.
Ahh yes sorry I did read it backwards.
Rest is all good. I wonder what on earth is wrong with the VST3 build in your environment. Juce 7.0.12 packages VST3SDK differently so I wonder if they have a Unix-vs-linux error in their make system and the target isn't being ejected. That would explain the break, which from reading the code can only occur if (1) you are building VST3 and (2) there is no VST3 target ejected by JUCE.
Harumph. I'll have to look at that. I'll rename this issue.
Bug Description:
Surge XT Version 1.3.2
Reproduction Steps: regular configure.
Expected Behavior: n/a
Computer Information (please complete the following!):
Additional Information: Can the pre-installed JUCE package be used? We have juce-7.0.7 that builds fine.