Missing "#if JucePlugin_Build_AU" in "juce_audio_plugin_client/juce_audio_plugin_client_AU_2.mm"

Hi there,

I am generating JUCE projects automatically using cmake which may contain AU format according to the platform (IOS and MACOS).

I noticed that in “juce_audio_plugin_client/juce_audio_plugin_client_AU_2.mm” the preprocessor check #if JucePlugin_Build_AU is missing. Is it possible to push a fix ?

Cheers,
Bastien

If I understood it correctly, AUv3 is for iOS and macOS, but AU is a macOS only format. So you shouldn’t compile juce_audio_plugin_client_AU_2.mm on iOS.

I’m also working on building JUCE projects using CMake in an open-source project called FRUT. There is no iOS support yet, but I’m actively working on it (I should be able to add the support by the end of the week, or next week). I’m always interested in having a look at how other people use CMake to build JUCE projects, so feel free to share something.

bump for this.

This is annoying when using juce-cmake in iOS mode.

Thanks !

I guess juce-cmake should be fixed then.

I beg to differ.
There are no reason to have some custom file to be opt-in or opt-out in the module depending on the platform.
That’s the rationale behind the juce module files where you should build everything.

No reason to hack something because of this.

2 Likes

The JUCE Module Format explicitly support including source files depending on the platform:
https://github.com/WeAreROLI/JUCE/blob/5.4.5/modules/JUCE%20Module%20Format.txt#L73.

I agree that the suffixes based on plugin formats is more of a hack than anything else. So are many things in how JUCE is built.

It doesn’t change the fact that juce-cmake is broken wrt. AU and AUv3 handling. It considers both to be the same thing (there is only a single juce_add_au function), but they are not.

However, it seems that the issue on iOS was fixed in a recent commit: https://github.com/remymuller/juce-cmake/commit/e511ffff8ea797d82f500602d30a766a3ffd816f, by simply excluding AU and AUv3 from iOS builds.

I work on juce-cmake with remymuller so I probably know more than you do on the project.

@Juce team, my fix request is still required as it avoids quirks in juce-cmake that shouldn’t be required.

@McMartin you are free to bend your code to fits the quirks in juce own code, I don’t do that :slight_smile:

Thanks !

Can’t see any harm in adding a guard to that file. I’ve added this in f86b33d, thanks!

Thanks. Much appreciated.

Should there be a similar guard in juce_audio_plugin_client_Standalone.cpp to ensure that it only builds in standalone targets?

1 Like

Yep, I’ll add that in too.