No rule to make include_juce_audio_plugin_client_VST2.cpp
Closed this issue · 6 comments
I'm using JUCE 5.4.7, and the git checkout version v2.4-372-ga91abe8f aka v2.5.0. When i do this make -f MakePluginEffect CONFIG=Release , i get this error message
make: *** No rule to make target '../../JuceLibraryCode/include_juce_audio_plugin_client_VST2.cpp', needed by 'build/intermediate/Release/include_juce_audio_plugin_client_VST2_dd551e08.o'. Stop.
I've managed to make -f MakeCabbageIDE , but not sure about this error.
You will need the VST2.4 SDK if you wish to build the VST2 plugin interfaces on Linux. If you don't have a copy of it, you should disable the VST2.4 option in the various plugin Projucer files. Btw, I'd move to the current dev branch if I were you. There are quite a few improvement since that version ;) If you don't need or want to export plugins then you can happily work away with just the main Cabbage application.
The v2.5.0 tag is for the develop branch though. And, i've found in projects that don't have a main branch to merge from a develop branch, there's usually breaking changes at the head. There's still the error with ../../Source/Utilities/CabbageColourProperty.cpp:198:47: error: cannot convert ‘ColourPallete*’ to ‘std::unique_ptr<juce::Component>’ also though.
It turns out that there were some mistakes in how i was building cabbage. I'd disabled the Projucer --resave in the buildCabbage script which meant that some objects in the generated Makefile were referring to non existent rules like the one above. So to build cabbage i had to add some juceplugin name strings defines in appconfig.h, remove the projucer version and convert the colour pallete to use std::unique_ptr. I had a custom csound installation as well, but even when adding this to the header/library paths in each of the jucer files, the linked version was always the system installed version. I had to change the runpath to use the custom install instead. It's a JUCE thing, but the search paths in the generated makefiles should include the custom install paths first.
Also, ldd seems to show that libldap_r is being linked in as well. Is there a reason for this?
I'm not familiar with this library. It is not being linked to directly as far as I can tell?
BTW, I will move to using CMAKE for the entire build process once I move to JUCE 6.0. This is current built system is a bit of a mess.
I think it works, just that my particular install had a newly compiled csound and projucer. On a default vanilla system with everything installed from the repo, it should compile fine.