JUCE should not be a git submodule

[Ben Vining]

Adding JUCE as a git submodule forces anyone building pluginval from source to redownload all of JUCE with the pluginval repository, even if JUCE is already present somewhere else on the machine. I would highly suggest simply doing find_package (JUCE) in the CMake configuration; for the Projucer, perhaps an environment variable could be set with the path to the JUCE sources?

[drowaudio]

The problem with trying to use a system-installed JUCE is that the API is extremely unlikely to be compatible with the app. The only way I've found to be sensible is to use JUCE as a submodule. The CI also needs that (or it would have to rely on some other package manager like vcpkg or conan).

[Ben Vining]

I can't speak to the Projucer, but in the CMake configuration, you can specify a JUCE version that is required, you can even say the exact version must be found, eg:

find_package (JUCE 6.1 EXACT)

If a system JUCE is not found, the Tracktion repo can provide a FindJUCE.cmake module that uses FetchContent to fetch the sources from GitHub (here's the one I use in my projects). This way, with no system JUCE, the sources will be fetched normally during CMake configure, and that should work for CI as well.