Hi there, the README for Pamplejuce (my JUCE plugin template) was getting a bit out of control, so I moved docs over to a dedicated home:
Feel free to let me know what you want more detail around.
I also plan on improving the project by taking better advantage of CMake options, which will make the shared CMake a bit more sustainable as a dependency going forward. For example, it will be trivial to toggle on ASan/TSan (and soon RTSan which landed in llvm 20).
A big thank you to all the contributors and everyone who has submitted an issue/PR over the last year or two!
By the way, what is the best way to convert a Projucer project to cmake ? And is there a path Projucer → cmake, so you can continue to use Projucer ?
That’s a good point, at some point I’ll do a migration to Pamplejuce from Projucer and document it.
In terms of reverting back to Projucer, it depends on the complexity of the CMake config, you can do a lot of things in CMake not previously possible in Projucer, not sure I’ve heard of anyone “going back” (but if so, chime in!)
I would be really interested to learn what I get migrating the code base to Cmake rather then staying with Projucer. So far, I can’t see that clearly. I understand that Cmake is a bare bones build system and anything specific about building audio plugins or crossplatform applications I have to do on my own.
Where CMake adds value is in automated builds (CI/CD) and cross-platform stability - once you get your plugin/app built, its a good idea to move to CMake-based builds because it allows you to offload the releases to an automated system, while also handling cross-platform targets smoothly. Projucer is good for getting to know JUCE, but when the time comes to ship there are a bunch of thorny things to be done where Projucer will just get in the way … codesigning, entitlements, and so on. Its far better to invest in learning CMake - in general, also - because a lot of the mundane automation tasks that a release engineer has to do, are covered in CMake land …
Try to treat Projucer as the scaffolding you need in order to harness your build tools to develop the product - but CMake is the finished road system that will make your app actually accessible to customers.
Nope, that is not true at all. We have a large scale application (Opus by EastWest) in production for over three years now. We have always had Jenkins continous build servers making various builds from branches and configurations on every git change. I can’t see how Cmake would improve anything. Xcode has commanline build tools that work very well. VisualStudio can be used fromn the command line too.
Everything else required for releases, like building installers, code signing, notorization is done with build scripts. Uploading to AWS and Google Drive is done by Jenkins.
So what is it that Cmake gives me ? Why would I use it and give up all the conveniences of Projucer ?
For me CMake pros are able to easier manage mulitple platform and clearly see flags and stuff like that in a global manner.
Like we have mulitple app so we can make sure all those apps uses the same flags by using global cmake helpers
For many, especially those starting from 0, it improves things because you don’t need to write all those manual build scripts in CI — everything is standardized.
In your case, you’re already setup and running.
So what is it that Cmake gives me?
Other nice things are:
Standardization across projects/teams and flexibility within a large maintained ecosystem.
It’s build configuration vs. spaghetti code (build scripts). Scripts tend to be brittle across compilers/operating systems/versions.
The configuration is explicit (vs. something you modify in a UI). This facilitates sharing/comparing between projects.
Complex dependencies are easier/possible in CMake. CMake is widely supported in the C++ ecosystem.
Adding JUCE modules (like my component inspector) becomes a 1-liner, you don’t need to manually juggle compile definition / preprocessor stuff for dependencies and it’ll “just work” in CI.
You could (and people do) build 10 plugins in a monorepo with CMake
With Pamplejuce (what this thread is about) you just need to call 1 command to configure and 1 command to build all plugin targets, including tests and benchmarks — on all platforms.
Why would I use it and give up all the conveniences of Projucer ?
CMake can also be a pain, yet another esoteric thing to learn. I would only only switch if you have a good reason.
But I 100% recommend it to people starting out and who want to build in CI — so much so that I maintain Pamplejuce!
