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.