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?
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.