Pamplejuce Docs Getting Started How does this all work? Setting up your project Setting up Code Signing Customization File Management Including files outside of /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? Using self-hosted runners Life with Pamplejuce Adding Tests and Benchmarks Clang Format Managing Releases How to update your Project Other stuff The `SharedCode` interface target 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
Including files outside of /sourceNext >
Private JUCE modules

Last Updated

Posted on 

 by sudara

Leave a Reply

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