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 > Other stuff > The `SharedCode` interface target
Table of Contents +

The `SharedCode` interface target

If you want to build both plugin targets and a test target, unfortunately the additional abstraction of the INTERFACE SharedCode target is needed. If you aren’t running tests (shame on you! jk) then you can edit the CMake and simplify.

The summary: JUCE modules build separately for each target (VST, Standalone, etc). You need to link against modules with PRIVATE visibility.

But both JUCE’s internal plugin shared code target (which powers the formats like AU, VST, etc) and Pamplejuce’s Tests target need to link against the same set of JUCE modules.

This becomes a problem when you link Tests to JUCE’s shared code target, as it causes ODL issues and confuses your IDE. Additionally, it is hard/impossible to set different compile definitions for the Tests target vs. plugin targets (for example, you’ll probably need to enable the deprecated modal loops, add guard macros for running tests, etc).

I spoke with Reuben at JUCE a bit about this here and there’s a Pamplejuce issue with background here.

< Previous
How to update your ProjectNext >
Example projects

Last Updated

Posted on 

 by sudara

Leave a Reply

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