Additional 3rd party JUCE modules go in /modules.
You can add third-party git submodules there (just like how the inspector is set up). Remember to not only call juce_add_module but add the new module to the target_link_libraries list!
I (and others, including some of the JUCE team) recommend moving as much as your application code into modules as possible, both for reusability and compile times. For example.
A few reasons to put your code in modules
- Re-usability. You can use modules across projects.
- Testability. You can test modules in isolation from each other. When sticking test in modules, it’s common to guard .cppfiles with something like#ifdef RUN_MY_TESTSand set viatarget_compile_definitionsinTeststarget.
- Sanity. You can keep the root project tidy, focused on the application logic.
- Compile-friendliness. Each JUCE module is its own compilation unit. If you change a file in a module, only that one module needs to rebuild. It also means you can work on only the module in a separate CMake project, which is a very nice/fast life.
Don’t worry about all of this if you are new to JUCE and modules. Just keep it in mind as you grow.
Leave a Reply