Creating an OSX JUCE app with CMake

Background: I had a working Qt app for OSX and wanted to replace Qt in the app with JUCE.

Detail: The previous (Qt) app was built with CMake acting on about a dozen CMakeLists.txt files. Apart from my own libraries built with CMake, some third-party libraries were also linked in.
Rather than put all my projects into XCode (tedious), I hoped a few simple manual changes to my CMakeLists.txt files would achieve the changeover. It turned out to be remarkably simple to do.

Assumptions: You know CMake (advanced knowledge not required)

  1. At a top level of your CMakeLists.txt build tree, add some lines describing your general JUCE requirements
    e.g.
    include_directories ( {SDK_ROOT}/juce/juce5 {SDK_ROOT}/juce/juce5/modules )
    add_definitions(-DJUCE_STANDALONE_APPLICATION -DJUCE_GLOBAL_MODULE_SETTINGS_INCLUDED )
    etc

  2. For any library you are building which needs JUCE, or for the app CMakeLists.txt file, you will need something similar to the following to include JUCE source along with your own:
    SET (sources
    {CPP_DIR}/MySourceFile.cpp {CPP_DIR}/MySourceFile2.cpp
    {CPP_DIR}/include_juce_core.mm {CPP_DIR}/include_juce_data_structures.mm
    etc
    )

Note the .mm suffix, which is vital for the compiler to handle JUCE correctly in the Objective C environment of OSX.

Your mm files will be of the form:
e.g.
// include_juce_core.mm
#include “modules/juce_core/juce_core.cpp”
// end of mm file

  1. Assuming your CMakeLists.txt tree is correct, if you are building and linking the app or dylibs you may get a whole load of link errors relating to OSX.
    You will not see the errors when building static libraries.
    They can be dealt with by adding framework names to your link command, like so:
    target_link_libraries( ${PROJECT_NAME} “-framework Foundation” “-framework Cocoa”
    “-framework IOKit”
    “-framework WebKit”
    “-framework CoreImage”
    etc
    The top two frameworks are probably obligatory.
    How will you know the names of the other frameworks to include? Look at the function names in the link errors, find them in the Apple online help and it usually tells you what framework the function is found in. It would be great if Apple provided a table mapping function names to framework names. Does anyone know of such a table?

  2. Suggestion: Build all your libraries with CMake, but use the Projucer to create an XCode project for the app. You will need to add the libraries built by CMake as dependencies in XCode’s “BuildPhases” tab. That way you can use XCode as a debugger and it will also step into and allow breakpoints on your CMake built libraries, provided they were built with the correct compiler debug mode switches, of course.
    Since CMake and XCode act independently, remember, if you change any library sources, you will need to run CMake to rebuild the libs before doing a build in XCode.
    I did have a problem with some dylibs not being seen as part of the mac app bundle (an infuriating rpath error), so I switched to static libs for debugging rather than mess about for hours with a simple debugging requirement that XCode should have taken in its stride. In any case, I will use third-party tools to create the bundle for distribution, so I can rebuild some libraries at that time as dylibs if I wish.

I hope this is useful and am always interested to hear improvements and suggestions. As a contractor for 30 years, I am naturally impatient, for my own sanity and for that of my clients, to try to find the easy answer. I intend to use the same technique for an iOS port: the libraries will be built with CMake and the app created in Projucer and built/debugged with XCode.

You can search the forum, they are already similar project doing this.



For the 4), you can parse the module .h
and check OSXFrameworks and iOSFrameworks values

1 Like

I don’t understand why you wouldn’t simply ask CMake to generate an Xcode project: cmake -G Xcode