Create custom JUCE module referencing other JUCE modules (gin, chowdsp_utils, etc)

General JUCE discussion
1

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:

Plugin_Project/ 
     Modules/
              foo_module/
              bar_module/
     Src/
     plugin_project.jucer
     etc...

My initial thought was to just install the other modules inside my custom module, like:

Plugin_Project/ 
     Modules/
          my_custom_module/
                 Modules/
                       foo_module/
                       bar_module/
     etc...

I haven’t seen this done ‘in the wild’ however, so any thoughts on how to approach this are appreciated!

2

I think all you need to do is add those other modules to the dependencies: in your module definition.

This doesn’t take care of making sure those dependencies are available though, which might be what you’re more interested in.

3

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:

git submodule add -b main https://github.com/rosshoyt/my_module modules/my_module
git submodule update --init --recursive

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:

juce_add_module("modules/gin")
juce_add_module("modules/chowdsp_utils")
juce_add_module("modules/my_module")

This is all sort of wild-west territory, but those are the options, I think!

1 Like
4

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.

Just do:
my_module.h

/*
BEGIN_JUCE_MODULE_DECLARATION
ID: my_module
dependencies: juce_audio_basics, chow_dsp
// ...
*/

#include <juce_audio_basics/juce_audio_basics.h>
#include <chow_dsp/chow_dsp.h>

#include "myHeaders.h"

// ...

Projucer / CMake are responsible to add the location of chow_dsp to the build. If you nest the files, the option in Projucer to relocate will get in trouble.

3 Likes