I am making a custom JUCE module to share my classes between multiple plugin projects. However, some of these classes use code from other independent JUCE modules. I’m wondering how to best organize the modules.
Currently, I have a single plugin project containing the code that I want to move to the shared module. My classes rely on code from foo_module and bar_module, which I added using with the ProJucer. The project is currently structured like this:
Since there’s no real dependency manager, my recommendation would be “good conventions, good docs.”
For third party modules like gin/chowdsp, maybe it’s a good idea to assume someone will not already have those in their project. You could add them as git submodules in your module (which references a particular commit you are compatible with). Then tell people how to install in the README:
It seems fairly common for people to place modules in a root level modules folder, so if you don’t go the git way, you can make it clear they’ll need to manually add the modules, place them at modules/gin (for example), and which commit/version you are depending on.
For projucer, you can walk people through what path to use.
For people on CMake, you can provide an example like:
Avoid referencing files inside the third party module directly. The juce module format is designed that the module header contains everything the user needs. You cannot rely on that the files and folder structure in the third party module doesn’t change at any time.
Your module should be agnostic to where the other module is placed.