CMake support in the Projucer

[t0m]

Hi all,

The JUCE team is currently investigating the best way of incorporating CMake support into the Projucer and it would be useful to get some community feedback. Please let us know, in as much detail as possible, how you would like to use CMake with JUCE.

At the moment I think the best workflow we’ve devised is to include a CMake exporter in the Projucer that is different to all the other exporters. This new type of exporter will contain a single input field that allows you to write arbitrary content at the start (and/or end) of the generated CMakeLists.txt file, and the rest of the build settings will be taken from the Xcode, Linux Makefile, and the latest Visual Studio exporters if they are also added to the project. The resultant file will then consist of multiple independent sections separated by operating system type.

Generating an Xcode project on MacOS would then look like:

cmake . -G Xcode

Would this configuration exclude anyone’s use-case?

[dstenning]

My interest in CMake support was in enabling me to use CLion with projects generated from PROJUCER but that was prior to XCode 9. Since XCode 9 finally offers refactoring features for C++ I will be sticking with Xcode on OSX for the time being.

Plus in any case - my preference - long term is for Projucer to become a workable C++ IDE in itself where possible - geared to maximise projects specifically written in the JUCE framework. Maybe final builds of apps for non-PC/MAC targets could be done in VS/XCode etc - but i’d prefer not to have to flip so much between PJ and IDE and stay in PJ for coding as much as possible.

[jonathonracz]

Please let us know, in as much detail as possible, how you would like to use CMake with JUCE.

My ideal would be a Projucer-free alternative system where I can simply add add_subdirectory(<path to JUCE module>) which would automatically add other required JUCE modules to my existing CMake project. When making a JUCE-centric project with lots of special settings and includes (like a plugin), add a CMake function or include-able CMake file which adds/defines all the additional stuff.

Additionally, by making CMake an alternative to the Projucer, you can avoid the odd project-generator-on-a-project-generator design you’re suggesting. You’d be positioning Projucer as a convenient alternative with a bunch of JUCE-specific extras + GUI + live building, while providing an open alternative to those who aren’t keen on Projucer tracking or need the extra features.

This essentially means that JUCE would be made CMake-compatible overall (which shouldn’t require any code or architecture changes to JUCE) by providing the relevant hooks for another project generator.

FWIW, I’ve been working on/off for a few months now on a Python-based generator for making includable CMakeLists.txt files from JUCE module descriptions, which is my personal ideal.

[anima]

It would be nice as a client of this to be able to write something like

find_package(juce REQUIRED COMPONENTS core audio etc)

and all the required files will be linked with the client application.

[mdsp]

I have been working on something like this this summer in order to migrate our build system to modern cmake that doesn’t require the projucer, uses juce module format and try to be as minimal, self-contained and non intrusive as possible.

Our requirements are listed on the README page

and a few example are available here:

For simple standalone use, I managed to only have to rely on find_package(JUCE) and target_link_libraries().

To be able to build plugins without too much hassle however, I had no choice but to provide a cmake helper function juce_add_audio_plugins() in order to select which plugin format to build and provide all the mandatory metadata.

Here is an example building the audio plugin demo.

One of the gotcha I had to deal with, is that if you want to allow building different juce projects using the same Cmake file (for example building all your products) and since juce requires an AppConfig.h file, each call to find_package(JUCE) has to generate a unique cmake target and associated JuceLibraryCode auto generated wrappers. I also had to rely on cmake INTERFACE_SOURCES property to postpone the compilation of juce sources on the final target.

Fortunately cmake is flexible enough to allow all these particular use cases.

My attempt is not as full featured as for example JUCE.cmake, but I’m quite pleased by the small amount of code required to bootstrap a new project, the readability of the produced cmake files and not having to rely on external tools.

We’d be very happy to see ROLI provide official cmake support for JUCE (like QT already does). If some of the cmake tricks I have used can be of any help feel free to use it as a starting point (that’s the reason why I published this on github).

I’m also quite sure that you also have your own ideas and requirements about the best way to provide cmake support but please keep in mind that for many reasons Projucer, while very convenient as both an project generator and an IDE, shouldn’t be a mandatory option for large scale development and build management.

IMO having the Producer to cmake export built on top of a library of JUCE/cmake support functions would make the generated cmake files more readable and allow people to use a pure cmake toolchain.

[jimc]

If it makes something I can use with CLion I’m in …

[yfede]

I’m totally with @jonathonracz where he says that having CMake as an alternative to Projucer would be preferred than having a two-step meta-project generation that involves passing through Projucer and CMake.

[basteln]

+1 for CLion. Working syntax highlighting, completion, etc. would be awesome.

[mcmartin]

I totally agree with @jonathonracz, @Anima and @mdsp. Before considering CMake support in the Projucer, let’s work on adding CMake support to the JUCE libraries. This is something I want to add to JUCE.cmake in the future, but if it already exists in JUCE, more people will benefit from it.

[matthieu-brucher]

That’s not really how CMake works. if you add a subdirectory, that subdirectory may add targets to your project, but it would make anything visible outside that folder.
Include a file, yes, but that should only make variables available like JUCE_MODULE_basics_SRC and _HEADERS.

Answering the OP question, a proper way to generate the CMake files would be to also allow for customiation of the CMake file. It’s a pain having to define all the variables for each exporter. CMake can handle that with find_package(), and then allowing a way to feed special includes, definitions and target libraries to a folder or a target.

[leehu]

Would this be able to generate Android Studio builds also and remove the Gradle intermediary?

[t0m]

Thank you, everyone, for the input.

I’ve spent a while looking at the possibilities, and, whilst I think there’s a lot of value in creating a Projucer-free CMake build system, adding a CMake exporter to the Projucer is much lower hanging fruit - we would be able to do this relatively easily and it would let people use CLion straight away, without significant additional configuration. Ultimately, if we have the required CMake infrastructure in place, we could then migrate this exporter to use new CMake functionality later on.

Unfortunately this work won’t remove the Gradle dependency.

[idearcos]

+1 on adding the CMake support as an alternative to Projucer.

I do enjoy Projucer, but for non-Juce-centric collaborative projects, I believe it’s a must to be able to build the project files with just CMake.

As others suggested, I would be happy if a call to find_package did most of the work (plus maybe some additional fine-tuning).

[harrycodex]

We use CMake for everything and just build JUCE as a library, no Projucer required. However we don’t use any of the more involved functionality (permissions on Android/iOS and all the audio plugin stuff) that Projucer provides so maybe our JUCE CMakeLists.txt is to simplistic.

[Achder]

For all those waiting for CLion support (and just in case somebody doesn’t know this):
You can also use JetBrains AppCode. As far as I know it uses the same code base and the interface is pretty much the same. The only difference is, it uses XCode projects instead of cmake.

[yairadix]

Thanks!

I’m giving AppCode a try now and it gives great meaningful warnings that Xcode/clang doesn’t give.

[eyalamir]

+1 on adding CMake support!
Using CLion is something I’ve wanted to do for a long time with JUCE, and having Projucer support is definitely my preferred way to go about it (to be able to share the same project with XCode/Visual Studio).

As for using AppCode: Unfortunately, AppCode is extremely buggy and currently has critical bugs when parsing code from JUCE projects, so it’s not very usable if you want to use any of the refactoring options or just look at code without false error messages that will eventually compile just fine.

I’m been following all their latest EAPs, but as of the current 2017.3 EAP it’s still not a workable solution for JUCE.

[Achder]

Did you try changing the context at the bottom in the very right corner?
Also, I had problems with C++11 features. Those went away after I set the “C++ Library” field in Projucer explicitly to llvm libc++.

Currently I’m error free from false error messages.

[matthieu-brucher]

The most complex part will be writing the bundle stuff in CMake!

[eyalamir]

What am I supposed to change ‘context’ to? I only see release and debug of the ‘shared code’ (When I open the DSPModulePluginDemo, for example).

Also, where exactly is the C++ Library field in Projucer and what exactly did you set it to? I was not aware of that feature at all.