# Compilerflags **URL:** \ **Category:** General JUCE discussion\ **Created:** [November 22, 2021, 9:07pm UTC](https://forum.juce.com/t/compilerflags/48892 "2021-11-22T21:07:22Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![D1rtyMusic](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/d1rtymusic/32/10801_2.png) [@D1rtyMusic](https://forum.juce.com/u/D1rtyMusic)\ **Post date:** [November 22, 2021, 9:07pm UTC](https://forum.juce.com/t/compilerflags/48892/1 "2021-11-22T21:07:22Z")
Is there a list with all compilerflags? In my case I have a plugin and there is an AU and a VST3 version. But as not all features are supported by both formats I have at some parts different code for the different formats and want to just compile it for the specific plugintype. I tried JucePlugin\_Build\_VST3 but these seems not to work, it still compiles it for the AU as well. ---
**Author:** ![mcmartin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mcmartin/32/7432_2.png) [@mcmartin](https://forum.juce.com/u/mcmartin)\ **Post date:** [November 22, 2021, 9:19pm UTC](https://forum.juce.com/t/compilerflags/48892/2 "2021-11-22T21:19:58Z")
It used to be possible to name your own source files `*_AU.cpp` or `*_VST3.cpp` and Projucer would only compile them as part of the specific plugin type target. It seems that this feature was deemed a bug and was removed in: > > > Fixes an issue where module sources with names including \`\_Standalone\_\`, \`\_AU\_\` > …etc. were added to the target for that plugin format, instead of being added to > the shared code target. I don’t know what the current way would be though… @reuk any pointers? ---
**Author:** ![D1rtyMusic](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/d1rtymusic/32/10801_2.png) [@D1rtyMusic](https://forum.juce.com/u/D1rtyMusic)\ **Post date:** [November 22, 2021, 9:45pm UTC](https://forum.juce.com/t/compilerflags/48892/3 "2021-11-22T21:45:50Z")
Hmm this probably wouldn’t be the best solution for my case anyways, as I just have a few lines of code that differ so something like > #if VST3 > … > #elif AU > … > #endif would be the kind of thing I look for. There are compilingflags like JUCE\_WINDOWS, JUCE\_MAC, etc. so I was wondering if there are some for the Pluginformats as well. ---
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [November 22, 2021, 11:00pm UTC](https://forum.juce.com/t/compilerflags/48892/4 "2021-11-22T23:00:51Z")
All your shared plugin code that you write is built only once into a static library. As a second compile step, the wrappers for each format are built and link against this library. This means that there can’t be a define for the plugin format since that would require that the whole code is compiled multiple times for each format. But you can query the public `wrapperType` member of your processor instance and put that logic into a simple runtime `if` statement in case that is a suitable option for you. [https://docs.juce.com/master/classAudioProcessor.html#a091b617d5bf926e54b510fb038917534](https://docs.juce.com/master/classAudioProcessor.html#a091b617d5bf926e54b510fb038917534) ---
**Author:** ![D1rtyMusic](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/d1rtymusic/32/10801_2.png) [@D1rtyMusic](https://forum.juce.com/u/D1rtyMusic)\ **Post date:** [November 22, 2021, 11:27pm UTC](https://forum.juce.com/t/compilerflags/48892/5 "2021-11-22T23:27:10Z")
For what I do right know this solution works fine, thanks. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [November 23, 2021, 10:46am UTC](https://forum.juce.com/t/compilerflags/48892/6 "2021-11-23T10:46:28Z")
The previous implementation seemed to be a bit too greedy with the filenames that it selected to be built into the wrapper targets. There’s a bit more info in this thread: [Bug? Filenames and underscores - #4 by reuk](https://forum.juce.com/t/bug-filenames-and-underscores/41534/4) It’s possible that the intended behaviour was to allow files with suffixes like `Standalone` and `VST3` to only be built into the corresponding targets, but I don’t think this behaviour is documented, and the previous implementation looked like an accident, which is why it was removed. If there’s a compelling use-case for this functionality, I’ll look at re-introducing it. In the meantime, I’d suggest using the runtime `wrapperType` technique that @PluginPenguin suggested instead. ---
**Author:** ![D1rtyMusic](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/d1rtymusic/32/10801_2.png) [@D1rtyMusic](https://forum.juce.com/u/D1rtyMusic)\ **Post date:** [November 23, 2021, 11:10am UTC](https://forum.juce.com/t/compilerflags/48892/7 "2021-11-23T11:10:07Z")
For know I have only two situations where I have differences between different “plugin” versions. As they don’t have any notable influence on CPU usage the wrapper version works fine. One thing would be that for DAWs that support it I use a Skin for my plugin that responds to the trackcolour, in my testing it seems that reading trackstats is not possible in AU, so this is why I made it exclusive to VST3 (and specific DAWs, as not all support it). I was just wondering if there would be a way to do this with compiling flags just in case I would have a similar situation in the future with a feature that has more impact in CPU usage. The other “feature” where I have differences is on iOS, here I add a keyboard-component to the standalone app, but not to the AUv3. But I guess this has to be done in runtime anyways, if I understood it right how AUv3 works. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [November 23, 2021, 11:16am UTC](https://forum.juce.com/t/compilerflags/48892/8 "2021-11-23T11:16:30Z")
> [@D1rtyMusic](#): > > I was just wondering if there would be a way to do this with compiling flags just in case I would have a similar situation in the future with a feature that has more impact in CPU usage. At the moment, there isn’t. If there were some facility that allowed source files to be built on a per-wrapper basis, then you might be able to forward declare a function like `Colour getSkinBackgroundColour (const MyAudioProcessor&)` and implement this function separately in source files for the VST3 and AU formats. For the scenario you mentioned, such a solution would probably be more heavyweight than necessary.