Although you already added that you won’t use CMake for now, I’d like to share a few general thoughts: You should not see CMake as a replacement for Xcode but as a replacement for the Projucer.
The Projucer allows you to specify things like sources and modules to compile, setting preprocessor flags, linking to libraries etc. Then you create exporters for Xcode, Visual Studio etc., let the Projucer create the platform specific projects and open them in your IDE. CMake basically does the same, but instead of a colorful Projucer GUI it is based on a scripting language. What’s called an exporter in the Projucer is called a generator in CMake. So a first basic workflow on the way to transition your project from the Projucer to CMake would probably be writing a CMake script, run CMake with the Xcode generator and open the resulting Xcode project and proceed as usual in Xcode to see if everything stayed the same.
But – and that is one of the big differences – you are not forced to use Xcode to build your CMake project on macOS. You can also use the makefile generator and use make as build system or you can use the ninja generator to build with ninja. The same then goes for Windows, you can create a visual studio project using a visual studio generator, or nmake, or ninja…
Beneath being able to use whichever build system you like, CMake gives you a lot flexibility in configuring stuff that would not be possible with the Projucer, especially if your project becomes more complex.
But no matter which build system you chose you still need a suitable compiler toolchain installed that this build system can use. You can install such toolchains in various ways, but it’s probably easiest to just install Xcode on macOS and Visual Studio 2019 on Windows as it installs those toolchains with the IDE – the other build systems can use them.
So you see: CMake makes things easier when it comes to more complex projects and allows experts to chose the tools suited best for every project, but if you are just getting started with it all, maybe Projucer will be easier to handle at first. CMake forces you to go a bit deeper and you need some time to get used to it’s syntax etc, but once you gained a bit more in-depth knowledge with CMake you will probably be quicker in finding solutions then before. In my opinion, it’s totally worth the time to learn it.
You should put them into your repository in a submodule. First of all this makes it possible for people to decide wether they want to clone juce along the project, but especially it helps you to keep track of the specific juce commit you are working on. With a submodule, you can always pull things from the dev tip into your project, and someone who cloned your project can see which juce commit you are working on. And when you work on multiple projects, the submodule approach allows it to use different juce versions for each of your projects – this will become especially useful for long-term projects.
). And as it’s known by many more people out there that might have never worked with juce it will make it easier for them to build your project.
As far as I remember proper CMake support has been a wish from the community for long and finally now JUCE made the move to add built-in CMake support. I assume the Projucer will be around for some more years, so currently these are just two equally good options, depending on what your goals are.
