Life without the Projucer

The Projucer
1

I build lots of things that aren’t audio plugins (i.e. they don’t use JUCE) and they all live in a shared repo. A few years ago, I managed to get both JUCE and my library of plugins building with Bazel in this shared repo [https://bazel.build]. It wasn’t easy, and it’s admittedly a bit of a maintainability hazard, but honestly I just don’t want to manage a bunch of apps [Projucer/XCode] to build a plugin and I like to share libraries between projects and so on. It’s invasive to the workflow I use for everything I build that isn’t an audio plugin. It’s just really nice to build everything in a single command line.

Now that I’m rolling forward to 7.0.7 (from a verrrry old version), I’m seeing lots of example plugins that seem to rely on generated code (that’s my understanding of what PIPs are). I don’t need to build those plugins, though it might be nice to have them as examples. However, the plugin host, which is incredibly useful, now relies on these PIP plugins, so I can’t build it without fussing with the Projucer (I think). I know my different workflow isn’t going to entice the JUCE train to change course, but is there a way we could add a preprocessor command or something that leaves out some of the extra generated code in the plugin host? I’m afraid one day the main libraries will get to the point where I can’t build them either and I’m just screwed.

1 Like
2

I haven’t tried myself, but it seems you can build pips from cmake:

juce_add_pip()

This function parses the PIP metadata block in the provided header, and adds appropriate build targets for a console app, GUI app, or audio plugin. For audio plugin targets, it builds as many plugin formats as possible. To build AAX or VST2 targets, call juce_set_aax_sdk_path and/or juce_set_vst2_sdk_path before calling juce_add_pip.

This is mainly provided to build the built-in example projects in the JUCE repo, and for building quick proof-of-concept demo apps with minimal set-up. For any use-case more complex than a proof-of-concept, you should prefer the juce_add_gui_app, juce_add_plugin, or juce_add_console_app functions, which provide more fine-grained control over the properties of your target.

1 Like
3

That’s an excellent lead, thanks.

4

A PIP is just a header file. In order to build and run it, you do need to generate some appropriate code to load and run the “main” class in the PIP, but it’s also possible to just include the PIP directly in a .cpp file and to use the classes defined in the PIP that way. This is the approach taken by the AudioPluginHost, so there’s no need to do any code generation there.

It’s also possible to build the AudioPluginHost using CMake rather than the Projucer, which might suit you if you prefer using commandline tools. There are some simple instructions for getting started with CMake in the main JUCE readme. The CMake target name for the AudioPluginHost is “AudioPluginHost”.

5

Thanks for the info and the reassurance. I’ll dig more into the CMake solution and see where that gets me.

6

This feels like a crazy dumb question, but in 30m I haven’t found the answer. Where does the output binary for this command live?

cmake . -B cmake-build -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build cmake-build --target AudioPluginHost

These files both exist and their names are familiar for compiler output, but when I execute them they do nothing apparent.
extras/AudioPluginHost/cmake-build/CMakeFiles/3.22.1/CompilerIdC/a.out
extras/AudioPluginHost/cmake-build/CMakeFiles/3.22.1/CompilerIdCXX/a.out

Building it was super easy, though.

7

cmake-build/extras/AudioPluginHost/AudioPluginHost_artefacts/AudioPluginHost

Found it!

1 Like