I’m trying to crosscompile a VST3 plugin on Ubuntu 20.04 with vanilla mingw64.
The plugin compiles and runs fine when compiled for Linux VST3, but when crosscompiling for Windows it seems that some macro is lost generated by the magic “juce_add_plugin” function is lost.
//win-release-build/_deps/juce-src/modules/juce_audio_plugin_client/utility/…/utility/juce_CheckSettingMacros.h:34:3: error: #error “You need to enable at least one plugin format!”
34 | #error “You need to enable at least one plugin format!”
I forgot to add the CMake toolchain file I’m using, but it’s nothing out of the ordinary, I’m setting the compilers/utils and CMAKE_SYSTEM_NAME “Windows”, CMAKE_SYSTEM_PROCESSOR “x86_64”, etc. Regular procedure.
if(APPLE AND (CMAKE_GENERATOR STREQUAL "Xcode"))
list(APPEND result AUv3)
endif()
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
list(APPEND result AU)
endif()
if(NOT CMAKE_SYSTEM_NAME STREQUAL "iOS" AND NOT CMAKE_SYSTEM_NAME STREQUAL "Android")
list(APPEND result AAX Unity VST)
if(NOT MINGW AND NOT MSYS)
list(APPEND result VST3)
endif()
endif()
set(${out} ${result} PARENT_SCOPE)
endfunction()
You might have very valid reasons to do not support mingw, but I’d have appreciated a loud and clear error saying that what I’m trying to do is not possible, as VST3 is a format supported on Windows.
Although VST3 is supported on Windows, I don’t think the VST3 SDK supports compilation with MinGW. The version included in JUCE definitely didn’t the last time I checked.
It’s a good idea to generate a warning in this case. I’ll see what we can do there.
Just out of curiosity, I tried to crosscompile with mingw on the LV2 fork (GitHub - lv2-porting-project/JUCE: The JUCE cross-platform C++ framework), as for my purposes LV2 is enough; I just want to sanity check on “wine/Reaper” while I develop on Linux and at some point before I make the plugins public just start sanity checking on Windows. I don’t like to develop on Windows.
With the LV2 fork I get:
/home/s0001192/oss/gogue/win-release-build/_deps/juce-src/modules/juce_gui_basics/native/juce_win32_FileChooser.cpp:235:17: error: ‘IUnknown_GetWindow’ was not declared in this scope
235 | IUnknown_GetWindow (d, &hwnd);
I spent some time looking at this today. It looks like the newest version of the VST3 SDK (3.7.2 at time of writing) builds cleanly with MinGW 8.1, and doesn’t require the extra definitions or -fpermissive. I think we’ll likely update the version of the VST3 SDK bundled with JUCE, and enable VST3/MinGW builds in CMake.
MIDISynth-Peak_VST3.vcxproj → C:\Users\leehu\dev\cpp\JUCE\Projects\MIDISynth\App\Nov\Peak\cmake-build\MIDISynth-Peak_artefacts\Debug\VST3\MIDISynth-Peak.vst3\Contents\x86_64-win\MIDISynth-Peak.vst3
‘attrib’ is not recognized as an internal or external command,
Normally MinGW/CMake errors that include is not recognized as an internal or external command indicate that there are incorrectly-escaped characters in the build commands. I’d recommend inspecting the problematic build command to check if there’s anything unexpected near the attrib token. You could also try using a different generator (e.g. Ninja), and/or running from a different shell (e.g. powershell/cmd/git-bash) to see whether that has any effect.
i’m trying to create scripts that run on mac and windows so that’s why I’m using git-bash.
cmd and powershell deal with the vst3 ok, but can’t run shell scripts.
so, how do I investigate further the “incorrectly-escaped” characters?
thx
To investigate, you need to look at the actual commands that are being executed by the build system. You can use CMake’s --verbose option to display the build commands as they run.
You also need to make sure that your chosen generator is compatible with your shell. MinGW Makefiles are only compatible with Windows command prompts, so I wouldn’t expect them to work correctly under git-bash.