AppConfig and Preprocessor macros


#1

I used to build AAX and VST3 plug in both, and wanna wrote some code to behave differently on each plugin type like this.
#if JucePlugin_Build_AAX
return “Some AAX_Host”;
#elif JucePlugin_Build_VST3
return “Some VST3_Host”;
#else
return “Not Support”;
#endif
I set the checkbox at Projucer ‘Build VST3’ and ‘Build AAX’ both. I found out that these settings are affect the AppConfig.h to define JucePlugin_Build_AAX and JucePlugin_Build_VST3 flags to be 1 simultaneously.
Meanwhile, In Xcode project it has auto generated build target settings which contains Preprocessor macros and it happen to be set like this.
JucePlugin_Build_AAX=1 JucePlugin_Build_VST=0 JucePlugin_Build_VST3=0 JucePlugin_Build_AU=0 JucePlugin_Build_AUv3=0 JucePlugin_Build_RTAS=0 JucePlugin_Build_Standalone=0 which seems to let plugin recognize the build target.

I checked out the flags on the runtime and it seems the AppConfig.h overrides the preprocessor macros. So it cannot distinguish on runtime whether it is AAX or VST because those flags are set to be 1.
I wonder is this normal behavior or I committed mistake. If it is how do I recognize the build target?


#2

Use the PluginHostType class at run time or AudioProcessor::WrapperType

https://juce.com/doc/classPluginHostType

https://juce.com/doc/classAudioProcessor#a7bf4a5cf41e84de51aab7ccb75d1f897

Rail


#3

Is there a compile-time way to know this, so that I don’t need to include certain code that is specific to a particular type, such as AAX-specific code when running a VST3 plug-in? No sense having that code compiled in at all if it’s never going to be used (and doesn’t make any sense to include).


#4

Projucer will filter files based on their name. If you have a file named Foo_AAX.cpp, then it will only be compiled in the AAX target (instead of in the SharedCode target). This guarantees that this file won’t be part of the VST3 plug-in for instance.

I hope this helps. Don’t hesitate to provide a more complete example of what you want to achieve and were you are blocked if my answer is not on topic.


#5

That doesn’t prevent the inclusion of a header file, though, or members or bases of a class that I only want to use in a particular type. At the moment, it is the use of derived classes that implement AAX control highlighting that I’d like to control, using the base class (e.g., ComboBox) when not using AAX, and using my derived class (e.g., ComboBox_AAX) when using AAX.