I decided to journey into the depths of CMake build scripts and try to build a CMake file that can properly build iPlug2 projects. Somewhat surprisingly, I was successful (with caveats).
First: I have a fork of iPlug2 with my changes (https://github.com/Bindernews/iPlug2), the most notable of which is the “iPlug2Config.cmake” file. I also have the project I and CMakeLists file I’m testing with (https://github.com/Bindernews/NESting/blob/master/NESting/CMakeLists.txt).
I tried to keep it as easy as possible, so basically you just declare targets as normal, then run a function which will configure the target according to the type of plugin you’re trying to generate.
One really cool feature, and my original purpose for doing this, is that you can add Faust DSP files to the build. They will be automatically re-compiled to .hpp files whenever the source .dsp file changes, just like any other normal build process. The purpose of this was that I wanted to split my Faust blocks into multiple files and then select which block I’m using at runtime.
Limitations:
Currently I’ve only tested this on Windows using the Visual Studio and Ninja generators, and only with APP, VST2, and VST3. It does not YET support MacOS, iOS, Linux, AAX, or WAM. Support will come for MacOS, Linux, and WAM. I don’t have an iOS device, and I don’t really care about AAX projects, nor do I own Avid, so I’m not going to be trying to build for those. That being said, I’m absolutely open to contributions.
Great stuff! There are other people working on Cmake support too. It would be nice to pool resources
Absolutely! Did I miss a cmake branch or something? Where can I find the existing work?
there is an old cmake branch here https://github.com/iPlug2/iPlug2/tree/project/cmake, but scott stillwell is also working on something better
Cool beans. Can we @scottstillwell or something? I’d love to pool efforts.
Also, do you like or dislike the way I’m approaching the CMake generator. Currently you build a project by copying an existing project and changing the settings as you see fit. I’m writing my cmake generator with the idea that you basically say “Here is my vst3 target, configure it to output a VST3”. Personally my goal is that users will be able to simply make a folder, write a simple CMakeLists.txt file and get going with their generator/IDE of choice. My ideal is that the examples wouldn’t have to include project files at all, just a CMakeLists.txt with the appropraite iplug2_configure(...) settings.
I realize it isn’t exactly a traditional CMake approach, but I think that, in this case, where there are so many different variables to control and so many different ways a person might want to configure their project, this approach will scale better and be easier for the users. But that’s my opinion, and you’re the project lead, so it’s up to you.
I need to have a play with it. Feel in a way that we already have one idiosyncratic build system, and one of the benefits of Cmake is to make that a bit more familiar and easy to integrate for people used to using Cmake, so it would be good I think to use Cmake in a non-idiosyncratic way!
1 Like
I thought about trying to write some CMake modules, but when I got into that, it started looking pretty confusing. I’ll take another look, maybe it’ll make more sense now that I have more experience with CMake. The biggest trouble that I see though, is the custom build steps that occur after various builds. From what I know of CMake, those will be hard to do with modules, so we’d probably want to end up keeping a function around to make those easier. And at that point, why use modules in the first place?
Maybe someone with more CMake expertise can chime in?
I’m here now - I wasn’t before. 
You aren’t finding my work because my repo is private on a private server. I was planning on cleaning up and publishing when done.
I’m not sure what opportunity there is to collaborate on my end, but I’m not opposed in principle. Certainly willing to discuss if nothing else.
Oh cool. Well I guess the question is what do you (@sstillwell) have working in your CMake build system? Or, maybe easier, what build targets aren’t working?
Alternately, what do you need help with before you’re ready to publish a version?
AAX, AUv2, VST2, and VST3 are working on macOS and Windows. Starting on AUv3 soon. We have one issue getting Carbon .rsrc files built for Component Manager in AUv2 (-comp flag in auval), but for modern hosts the AUs validate just fine.
Well dang, that’s sweet. Can you add multiple Faust DSP files? That was my original purpose for using CMake, was to have CMake automatically re-compile my Faust files when they changed, and to make it work cross-platform.
Haven’t touched standalone apps, iOS, WAM, or Faust…not likely to for our uses. Once we publish we of course would welcome non-disruptive changes even if we don’t personally use them.
Alright, sounds good. I have things working for standalone apps and I have some Faust stuff working. Hopefully I can get WAM working, but I’ll probably wait to see what you have done until I start working on that. That being said, do you have any ETA on a release date? Are we talking this month, 2-3 months, or longer? I’m not going to hold you to anything, just trying to decide how much more work I should put into this on my own, or if I should wait for you to release and integrate my changes with yours.
We’re moving ahead with all due speed…I’ll start getting annoyed with myself if this isn’t complete for our purposes a month from now.
Lol, I know the feeling. Well with that in mind, I’ll hold off on making major changes to my stuff until your changes are public.
Well I guess I lied. I rewrote my entire build-script to be more in-keeping with modern CMake. There’s still a configuration function, but it’s only for things like post-build events. Now you can link different parts of iPlug2 as libraries (e.g. target_link_libraries(MyApp-vst3 PUBLIC iPlug2_VST3 iPlug2_GL2 iPlug2_NANOVG iPlug2_Synth) will make MyApp-vst3 a VST3 plugin that uses GL2 and NanoVG for graphics, and includes Extras/Synth for making an instrument.
Credit where credit is due, this is way nicer than writing build scripts used to be, and much easier to manage long-term.
1 Like
The learning curve is pretty steep at first, but I’m really liking the repeatability of it. It’s fitting in really well with our CI/CD system (GitLab CI) and making build-and-test on every push a practical possibility. We were doing it before, but keeping the Bash script and Windows batch file in sync (and alllll the project files) was not always easy.