Pamplejuce Docs Getting Started How does this all work? Setting up your project Setting up Code Signing Customization File Management How to include files not in `/source` JUCE Adding JUCE Modules Private JUCE modules Dealing with Binary Data JuceHeader.h GitHub Actions 101 Tips and Gotchas How do GitHub variables work? Life with Pamplejuce Clang Format Managing Releases How to update my Project Other stuff The `SharedCode` interface target Public example projects Original References & Insipration
Pamplejuce Docs > JUCE > Adding JUCE Modules
Table of Contents +

Adding JUCE Modules

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 .cpp files with something like #ifdef RUN_MY_TESTS and set via target_compile_definitions in Tests target.
  • 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.

< Previous
How to include files not in `/source`Next >
Private JUCE modules

Last Updated

Posted on 

 by sudara

Leave a Reply

Your email address will not be published. Required fields are marked *