###################################
#             README              #
###################################

This is what my solution for using JUCE with bazel looks like. It allows me to build AU/VST plugins
on OSX and VST plugins on Linux and OSX.

Tested on Catalina and Ubuntu with Juce 6.1. Are other things supported? I don't know.

JUCE is very complicated in the way it is built. To the JUCE team's credit, they're working hard to keep a ton of little messes from being my problem (like multi-OS support for plugins without me having to know how horrible working with VSTs or AUs directly might be). This complication is hidden by the ProJuicer, which is fine unless you like the command line and like knowing what is being managed behind the scenes. JUCE has a backwards dependency on your project in the form of preprocessor macros. In other words, you don't really build it as a standalone. That's not a problem if you have one project or prefer to work in self-contained project libraries, but I personally prefer to use a monorepo [https://en.wikipedia.org/wiki/Monorepo] and so sharing JUCE across projects isn't obviously easy. I configure this using a per-project flag. It's a little annoying, and I'm interested in better solutions if you have them.

###################################
#          SYSTEM SETUP           #
###################################
First install bazel, obviously. Most (maybe all) of my scripts are intended to be run from the WORKSPACE directory.

I have JUCE configured like a git submodule. So to set that up, you can do the following command. It will checkout version 6.0.1.

git submodule init
git submodule update

Now you're ready to get started. Build the JUCE Demo Plugin.

bazel build -c opt --copt=-fvisibility-inlines-hidden \
  MyAwesomePlugin/MyAwesomePlugin.so \
  --define="mode=plugin" \
  --define="project=my_awesome_plugin" \
  --noincompatible_remove_legacy_whole_archive

If you're thinking to yourself that that's horrible, I agree and that's why I wrote the MyAwesomePlugin/MAKE script. It's not a proper makefile, you can yell at me if you want, I guess. In general, you only need the copts and the final flag when you're building the final plugin. If you're just testing its dependencies in a cc_test or something you don't need them. They have only to do with building the shared library.

Sorry I no longer have build rules for things like the JUCE plugin demo. JUCE's demos get more and more complicated if you aren't using the Projuicer and I could be bothered to learn what a PIP is or how to make it work with Bazel.

Looking at those --define flags, that is the manifestation of the backwards dependency I mentioned above. If you look through the ThirdParty/Juce/BUILD file you can see that that isn't required for building the PluginHost. Since those and all of their dependencies can rely on the same JUCE target, you can make a special JUCE target that doesn't involve those flags. I use those flags as a way to support having a shared codebase (SharedLibrary is my minimal example in this repo) and several project that depend on them (PluginDemo doesn't depend on my shared library, but with this setup, it could).

If you run MyAwesomePlugin/MAKE, it will do some stuff behind the scenes and make your a plugin file. Add the -d flag and it will deploy the library to your VST/AU folders. Once you've done that, you can test this using the PluginHost.

ThirdParty/Juce/PluginHost/RUN

It is convenient to pass a graph with the -g flag to this script so you can have a pre-built pluginhost graph.

You may have to scan for plugins and all the usual things.

###################################
#          NEW PROJECTS           #
###################################

For making an audio plugin, you'll need to implement a PluginProcessor and a PluginEditor.
Following that, you'll want to make a few small edits in /ThirdParty/Juce/BUILD. Write a Config target containing all of the project-specific macros that are required when building JUCE.

That's all that is necessary to build. Remember to pass some command line flags when attempting to
build.

For example:
blaze build MyProject:Main --define="project=myprojectname" --define="mode=plugin"

Without the last flag, you'll get an error about JucePlugin_Name being undefined.