If you can’t even compile the Projucer then you probably shouldn’t even be trying to learn the rest of the framework yet, because at some point you’re going to have to compile the Projucer (and it was endlessly having to do that which pushed me into CMake).
And again if you’re afraid of the terminal, perhaps learning C++ and JUCE isn’t the right initial step on the journey.
These are of course just my opinions and can be safely and roundly ignored!
My main point is that I’ve learned plenty of times from “beginners” guides very bad habits. The trick would be to explain the good habits to beginners in a way they can understand. Perhaps easier said than done though.
Don’t get me wrong, it would make sence to create such a tutorial, but it’s not very suitable for a beginner. I don’t assume, that the reader has any knowledge about CMake and just wants to do stuff like the framework wants to. CMake is very powerful and so is git but in my opinion, it would not make sence to throw CMake, Git, JUCE, maybe even C++ at a beginner.
I get your point but I think, this is the reason why so few tutorials are actually great. They assume, that there is a huge amount of pre-knowledge and not just let the reader decide, what he already knows. Maybe he wants to know everything from ground and maybe he just wants a code snippet. Either way, its better to explain everything for the first example since someone who wants a code snippet maybe doesn’t really know whats happening and wants to learn about it too.
I see it more like this. There can be a tutorial for C++ development in JUCE. There can be a tutorial for how to maintain a build infrastructure to really exploit JUCE’ crazy multiplatform and multihost capabilities. There can be a tutorial to focus on only GUI, only DSP.
Well, you get the point. But, if the standard were set for all ‘next-gen tutorials’ that are part of this effort, please just make a spec for the tutorial whereby, git usage is encouraged, if not required.
The reason for this is, JUCE with CMake and git make for a very interesting constellation of tooling and methodology practices, which - in the right balance, produce amazing stuff.
You can’t just throw C++ into the JUCE context (but of course must), and not cover the rest of the pieces, which are actually also related to why C++ is being so well and effectively applied in this project. Learning to tame CMake will actually make you a better C++ programmer, because C++ programmers must, by necessity, understand tooling, architecture, and execution environments rather well, in order to write effective code.
Also, there can be beginner and advanced tutorials. CMake is not advanced, imho, its also good for beginners.
As long as the tutorials follow similar principles, I’m sure its going to be great to see.
It’s worth considering that a lot of people come to JUCE because they’re musicians/producers who just want to have a go at making their own plugin - not because they’re wanting to start a career as an audio programmer.
Sure best practices are good to impart if that’s what the person wants to learn, but if they just want to learn how to write some basic code to make weird sounds then there should be a tutorial for that too.
Wanting to lower barriers is definitely a big driving force for why I bother writing or blogging anything. Even selfishly, it could also be future-me in 6 or 12 months wondering wtf hurdles I jumped through and why.
C++, JUCE, git, CMake — all very “deep” worlds, but each of those barriers can still be lowered and best practices communicated to save everyone time. Doing so might be the difference between someone sticking with learning things vs. giving up because they feel everything is esoteric, crusty, or just not clear enough.
That being said, I agree that learning 10 basic git commands in 2025 is a good idea, otherwise you’ll be locked out of a lot of third-party stuff, collaboration options, and basically all modern development best practices. In other words, there could be a “Getting started with git” section it the API docs which shows a few basics for anyone wanting to level up.
The markdown version of the tutorials themselves are published but the goal was to make them public, thanks for the reminder!
Re: more API docs like we’ve been talking about in this thread, for ease of getting them done I’ve been writing them in JUCE’s CMS (wordpress, which I’m very familiar with) but they could be transitioned to the same markdown->wordpress flow that I set up for the official tutorials.
Imho git and cmake should be optional and tutorials should teach beginners the benefits of using them instead of imposing them as a mantra.
In fact, I don’t get the point of using Cmake if you don’t have dependencies outside JUCE modules. I love the freedom of using any scripting language to preprocess data and later, handle permissions, generate installers, sign and test. Can somebody sell Cmake to me considering how expensive it is in terms of learning its syntax and adding yet another layer to install and maintain?
If Projucer works you, you are happy building individual projects locally and don’t have clear pain points with dependencies, IMO there’s no reason to feel any FOMO with CMake. I wrote the points I like about it here:
Perhaps this is a style thing, but in my codebase, most of the code is outside of JUCE/the module system. We only use JUCE for the UI and the plugin wrappers, but all the DSP/model/file handling code is “regular” C++.
This might be more of a point for this project architecture than CMake per se, but adopting this structure of moving code into “regular” C++ libraries where possible has vastly reduced build times, especially for test executables.
CMake makes it easier to do testing, you can configure a test executable in the same project as your product, and the ctest program makes it easy to run all your tests & get a report.
If you have any kind of “superbuild” with multiple plugins/apps in a single project, you can do this just fine with cmake, but AFAIK this isn’t supported by the Projucer.
If you do have dependencies, cmake makes finding & managing them easier than Projucer.
Any kind of options that may parameterize the build, cmake makes it easier to work with them. This is because cmake is actually a scripting langauge, whereas a Projucer project file is a static XML data file.
All these things of course are possible within cmake. If you already have custom scripts for these tasks, it should be pretty easy to set up cmake commands to run those scripts.
In theory it’s a very similar technique, but the CMake logic to create a unity build is a bit intelligent, it can do things like batch the translation units so that they’re all about the same size, or none is larger than some maximum size, etc.
CMake provides different algorithms for selecting which sources are grouped together into a bucket.
Interesting. It’s cool to hear how people are using CMake. Thanks!
I totally subscribe to that.
I still think though that the other things that you mention can be handled in standard scripts (and python/bash/bat are more powerful imho if you need to do something ‘special’). Parametrizing builds with macro variables is not an issue, you can call multiple time Projucer in your scripts.
Some things I like about Projucer are: dragging and dropping a bunch of resource files as binary data, having them indexed in a visual file tree where you can collapse folders and having theme-grouped dropdown menus + info tooltips about each option that can be configured in JUCE as opposed to having to memorize all those options (or having them commented in a huge linear configuration file) and having to navigate the CMAKE documentation.
That’s true, and if you have custom build steps that need to run a script, you can have cmake do that. You can also have arbitrary test commands to be run by ctest, such as invoking a Python script, etc.
Sure, but it’s still clumsy to actually get different data/options into the Projucer file, since the PJ file format is just static XML that doesn’t support any kind of variable expansion AFAIK. So I’ve seen multiple people doing things like writing scripts to auto-generate or edit Projucer files and then invoke the Projucer… IMHO that’s hacky and more complicated than just migrating to a proper build system that is designed for these kinds of more complex use cases.
Many IDEs have great CMake integration, personally I use CLion.
Are you referring to the various preprocessor flags that can be set for each JUCE module? That is a handy feature of the Projucer. CMake has no integration for preprocessor flags themselves, but for CMake variables/options, there is a TUI cache editor & GUI app available that will provide doc strings for each option.
