How to get started with CMake and cross-platform

I have written a small Juce cmd line tool (osx) and would like to compile on windows now. So two questions.

1 - what is the easiest and most simple way to get a very simple CMake configuration happening so that I no longer need to build in Xcode? Eventual goal will be to have easy ability to compile for cross-platform. I don’t know anything about Cmake right now and of course will learn more and more over time, but for the moment looking for the quickest way to get up and running with a simple CMAKE configuration instead of Projucer/Xcode…

2 - I will have to build windows on a VM. what tools do I need to install under windows in order to support building JUCE apps and plugins using CMake?

Never mind question #2, I installed VS Community 2019 and Projucer. was able to build my project under windows on VM, no problem.

CMake…that’s another story. Had a look at the consoleApp example in the JUCE examples directory, but could not get anything working…don’t even understand how I am supposed to point it at the juce core stuff properly.

I will just forget about CMake for now, way too much to learn about that and no time at the moment.

Would be monumentally easier and better of ProJucer could export a simple Cmake config.

I will be putting this source on GitHub eventually, and another question that always comes up for me whether I should be including the juce source there along with my source in order to make something that will be easy for other people to clone and build. Ideally I’d like it if someone can clone the project, cd into a directory and type a single command to build my app…on either platform.

Right now, the process to build on Windows was kind of complicated, have to open Projucer, from there export out to VS, then load VS and the build it, then look through a lot of directory levels to find the executable. Well CMake I’m confident could make that whole process a lot easier…and I’d just like to get used to using CMake instead of Projucer frankly, but I have a lot to learn about setting up CMake and JUCE on CMake…and presently no time…and the examples aren’t generic enough to work quickly…unless someone has more quick tips to get something working quickly in a simple way for now…but I think I’ll just forget CMake for now. Like where JUCE is heading with that I guess… Too complicated to figure out right now.

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.

Yea I understand CMake is not the compiler. Just want to set things up so that the procedure for building on OSX will be nearly identical as building on windows…(not counting the part about installing all the right tools). In unix land there are so many open source projects where you download the source, type ./configure;make and have a working binary after that. That is what I’d like to be able to get happening my JUCE projects. I hear you that CMake is really suited for MUCH MUCH more complicated tasks on large projects…which I am not doing…so maybe CMake is entirely the wrong tool to use, I don’t really know since I don’t know the details about CMake yet…but since Roli is focusing on CMake as build-configuration, I guess I will get to that eventually, but not now…too much to take on for my simple project at this point.

Thanks for the tip about the submodule. Here’s the thing, I am actually using GitLab, not GitHub…so…JUCE is on GitHub… I’ve never setup a git submodule before…so another thing to learn…and particularly if my source is on GitLab and the submodule is on GitHub, so you see any issue there?

But the point about being able to specify the exact version of JUCE to use that way makes sense. In my case I’m using Projucer…which is fine…its just kind of a manual process to build, etc… but the juce core files all get copied from the “current” JUCE that I have installed and build into the project and for my purposes right now, that is fine. So at the most simple level I’m inclined to not check any JUCE files into my GItLab…nor refer to submodules…just save the .jucer file and my sources and then anyone that wants to try to build it can figure it out themselves.

I’ve seen other juce projects where people actually checked the juce core module sources into their project, and personally that just seems wrong to me for a number of reasons…the submodule approach seems the right approach, but I have to figure out how to refer to a submodule on GitHub while my own project is on GitLab. That will matter a lot more in the future as I work on larger projects too.

Yes, if you want that, CMake is probably the right way to go (where it then would be something like cmake ../; cmake --build . :slight_smile: ). 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.

First of all, JUCE is not owned by Roli anymore for nearly a year now but now is part of Pace :wink: 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.

Regarding the submodules and GitHub/GitLab, this is no problem at all, I have successfully done that myself before. Git itself is the standard that defines submodules, whoever runs the git servers does not matter, afaik the JUCE team uses GitLab itself internally and only uses GitHub to share their repository with the public

Yes, if you want that, CMake is probably the right way to go (where it then would be something like cmake ../; cmake --build . :slight_smile: ).

Yea something like that is what I’d like to shoot for eventually. I will look into that later. Ultimately I am going to provide binaries for OSX/Windows anyway, so in reality the only people that would need to compile the source would be people wishing to fork it, change it, tweak it, etc…and they probably will need to learn a little juce anyway. so it might be fine to just include the .jucer file and my sources.

But in addition to just making it a little easier for someone to tweak a little something and re-compile it easily…I also like very much having a make-driven approach, so that I can build in compile-time tests and things like that without having to monkey around with Xcode… (and of course all that stuff should run on any platform also).

anyway I’ll save it until I have some time to learn more about CMake.

Regarding the submodules and GitHub/GitLab, this is no problem at all,

Excellent thanks. I’ll look into that today.

afaik the JUCE team uses GitLab itself internally and only uses GitHub to share their repository with the public

nice to know!

so getting back to best-practice on setting up my project…

Let’s say right now I have a jucer file and I have my sources. When I export from ProJucer, it automatically copies the juce module sources into JuceLibraryCode, and my sources into Source, and saves the Xcode project file to refer to all those things so its buildable in Xcode.

If I were going to keep using Projucer for now, how would I go about referring to a submodule rather than the JuceLibraryCode folder that Projucer is copying automatically from my current Juce installation every time I have some need to change something in Projucer and re-export it to Xcode/Visual Studio ??

This behavior can be adjusted on a per-module base in the Projucer.

If “Use global path for this module” is ticked, it will look for a global juce installation and take the module from there, otherwise you need to specify correct paths for each platform. If “Copy the module into the project folder” is ticked, the module will be copied, if not, it will just generate a slime header with an include directive pointing to the original location.

So what you want is to uncheck both and set a path to the JUCE module folder contained in the project for each exporter. Once you adjusted one module, click on the gear icon on the bottom just above the Exporters panel. Here you can copy the settings adjusted for that one module to all the others.

1 Like