[FR] Allow other code modules to leverage the `_FORMAT` syntax

My biggest blocker for migrating to CMake from Projucer (Anthony, look away) is the lack of support for modules other than juce_audio_plugin_client to specify format-specific compilation units, e.g. my-plugin_vst3.cpp I have made a very minor modification to the Projucer in our JUCE fork to allow this, but the equivalent behavior via CMake seems to be more involved.

For some of our legacy, pre-JUCE plug-ins I need to have a lot of code for handling session state loads and don’t want to pull all of the logic and dependencies in to every plug-in format (e.g. needing to pull AAX SDK headers in to the VST3 binary).

I understand there’s a risk of breaking existing projects with a change like this, so perhaps adding an option to the `juce_add_modules function which defaults to the existing behaviour would allow this feature to be added safely?

I might misunderstand the problem (as I haven’t used Projucer before), but perhaps you can do something like this in CMake:

if ("AAX" IN_LIST FORMATS)
    // do something here
endif ()

Each format makes its own target in CMake so you should be able to do something like:

juce_add_plugin(MyPlugin ...)

target_sources(MyPlugin
  // Common sources...
)

target_sources(MyPlugin_VST3
  my-plugin_vst3.cpp
)

No guarantees that works in practice though.

We have our product and common framework code formatted as JUCE modules for easy inclusion in the Projucer, so with CMake I would like to simply add the modules in same way. At the moment, any file with, for example, _VST3 appended to the name is included in the Shared Code target, which isn’t the intent. To do what you suggest I could move all of the format-specific module code in to a new folder inside of the module and not include the .cpp files in the main module compilation unit build file and then manually add each to the targets like this.

I think that would probably solve the issue, but it isn’t very elegant and adds more friction to the process of migrating from Projucer to CMake (granted, friction of my own making after modifying Projucer). It is also not very practical for each shared code module across all jucer files we maintain (19 at the moment) and for new projects I have to remember to manually add format-specific files in this way for all of the common code modules, which is error prone.

I still think that widening support for target-specific module compilation units as in juce_audio_plugin_client would be a useful feature.

1 Like

Are you able to share the changes you’ve made to the Projucer just OOI?

I do agree that some ability to query what format is currently being compiled would be useful - something agnostic of the build system being used.

At a glance, I believe the only change I made was to the isPluginClientSource lambda inside Project::getTargetTypeFromFilePath in jucer_Project.cpp:

- auto prefix = pluginClientModuleName + “_” + suffix;

+ auto prefix = /*pluginClientModuleName + */“_” + suffix;

Our fork is based on 8.0.8, so this may not track with the latest master or develop branches.