I’m using juce_add_plugin to build my plugin with CMake. I noticed this creates an artefact called libProjectNameSharedCode.a which I take to be a static library that is used when building the various plugin format binaries.
I have a target that builds my unit tests using juce_add_console_app(Test), and I would like to link the shared library to this target as well.
In target_link_libraries you can also specify another CMake target – if this target generates a library it will link to it. This also ensures that the specified target will be built before you attempt to link against it, which is not guaranteed with your approach. And it propagates all the PUBLIC or INTERFACE properties set to the library target like e.g. header search paths, compiler flags etc to the target that links against it.
juce_add_plugin(my_plugin) creates multiple targets, which are my_plugin (building libmy_plugin_sharedCode.a on unix or my_plugin_sharedCode.lib on Windows) and one for each plugin format, named e.g. my_plugin_vst3.
So all you want for a cross platform test target is
This comes from using juce_add_console_app. The JUCE settings are then defined twice: once from juce_add_console_app and once from linking against the plugin.
You should try using a regular add_executable(Test) to create the test executable.