CMake module for openFrameworks


Continuing the discussion from Make install target, shared object build:

Related to this, is there a CMake module available which allows cmake projects to easily find the deployed (?) openFrameworks libraries? I can’t find one in the source tree.



generally the project generator includes a Makefile with the project that you can use to compile your app, but I’m under the impression that that’s not what you mean


Nope, and I am not really a big fan of using a project generator of some library on which my software depends in order to build my own (JUCE has this same conception with their Introjucer). I know that for many people who want to get started quickly and do everything in openFrameworks that’s a convenient way to go about things, however for people who want to manage their projects by their own means, there should always be a “regular” alternative for developing against a library.

Since CMake is becoming rather widespread especially for cross-platform projects, I think we should supply such a CMake module together with openFrameworks, so it will make it easier to include openFrameworks into CMake based projects.

If noone has written one already, I will see that I write a module and contribute. However I think the question of openFrameworks deployment (see linked discussion on make install target) should be answered first.


@procedural has dedicated quite a bit of time to the cmake question. Check out his approach on his github and see the forum and dev list for more.


Also, you can join this discussion on Github, but I don’t think you can expect openFrameworks to make a switch to CMake any time soon due to different constraints it have.


I think you don’t quite get my point, JUCE can be built whatever the lead devs / majority of devs prefers or even provide / maintain different build systems. These CMake modules are just small files setting up some variables with paths, etc. as such that other projects using CMake need to do a simple ‘find_package(openFrameworks)’ in order to have linker/compiler flags etc. properly set up and quickly start working with it.

I will just write that thing, issue pull request and you’ll see how that works out.


It is actually described in the link I provided, but don’t bother I’ll just do it. However the question of “installation/deployment” needs to be resolved first, i.e. do we want to properly deploy the project in lib/include directories which can be installed to some root directory, (/usr, /usr/local or some user-defined prefix) as it is customary for software deployed on UNIX systems.


Yeah, that’s actually the reason why mine ofnode/of project didn’t used find_package() command: it expects to find openFrameworks in one of the hard-coded and protected by the root user global paths. Even if you’ll figure out where the libs and include files should be placed, currently openFrameworks depends on patched glfw library (but maybe oF will switch to official glfw for a final 0.9.0 release) which will force you to have its copy in the system even if it has one already. Add to that the headache when CMake will try to link wrong library and you’ll understand deeply how messed up the idea of seeking for something globally is (IMO, of course).


This is not true as it stands, refer e.g. to CMAKE_PREFIX_PATH documentation. I will just sort the stuff out and issue a pull request. Regarding the 3rd party libs I already stated my opinions, and regarding your last statement I very strongly disagree. We don’t want to start deploying software in the conceptually broken way as it is common on MS and Apple platforms, at least I will refuse to do so.


Cool, then go for it! :wink: I’m genuinely curious to see the result.


Well as said, I would actually prefer to have the deployment question sorted out first. But yeah… I think that will require some discussion so I’ll just write the CMake module such that it locates the libs/headers inside the oF source tree (which really sickens you as a package maintainer on unix systems ;)), adapting it afterwards when the deployment is sorted out will be no big effort. Stay tuned!


Ok so there you go:

Look at PR content if you want to know what such a cmake module config file does. Basically setting openFrameworks_INCLUDES and openFrameworks_LIBRARIES properly…

In my example CMake project using this, it looks like this:

set(PROJECT etudes)

cmake_minimum_required(VERSION 3.0)

set(openFrameworks_DIR $ENV{OPENFRAMEWORKS_ROOT}/cmake)
find_package(openFrameworks REQUIRED)

add_executable(${PROJECT} src/main.cpp)

    PUBLIC ${openFrameworks_INCLUDES})

    PUBLIC ${openFrameworks_LIBRARIES})

So yeah that’s basically it, working CMake project building against openFrameworks. All I need to do as of now is to set OPENFRAMEWORKS_ROOT in the environment before invoking cmake, due to the fact that oF is not (yet) deployed in a standard fashion, where if installed systemwide it would be found automatically, or, if installed in a custom location, I would need to set CMAKE_PREFIX_PATH as usual. If people want to test this after it’s merged on VS and osx that would be great, since I can’t.


As @procedural noticed already, I was missing quite some aspects, mainly because we are doing a static library build. The discussion is linked in the other thread. I thought that practice has long long been superseded and there are reasons for that after all. Anyways I won’t rest until this is resolved in a conceptually nice way, non-invasive to the current way oF is built, but which will enable external projects with their own build systems to make use of the library without investing tons of effort.


Just an update, have it working nicely on Linux. However it’s not yet tested on mac os / windows. I’m currently busy setting up my mac machine here at the new workplace, will port it to mac then as well and update the PR.


Well since I don’t have access to my mac over the weekend, I just pushed the changes working for me on Linux, ,so people might give it a try over the weekend so I can start incorporating fixes etc. when dealing with this next week. @procedural I’d be interested in what you think about this. Please only test this when you’re on Linux, I know for sure Mac/Win won’t work like this. Just pull my feature-cmake-config branch to test:


Update: works on mac os now (for me at least) for people interested in this, you might want to give it some testing. For an example CMakeLists.txt for an application using this see earlier post.


This project risen from its ashes here : (yes this is the same place as before)
since the original project by @procedural disappeared with its author, some content is missing like know bug section and wiki pages.
I’ve updated the source with of 0.9.3 and it’s working on Linux, OS X is in testing (see Travis :


Dear all!
I worked on a simple version of CMake. It works for Mac OS X. Other OS will be supported soon. It should be easy to use, easy to be extended and works fine with CLion!

I started a new discussion thread for this version:
CLion and CMake support

Hope you like it


OF is synced with openFrameworks 0.9.8 !

And now you can easily cross compile for Raspberry Pi under Ubuntu.
A step by step tutorial is here :
The hardest step is to build a Raspberry Pi image with all needed dependencies.

Of course, you can still build on OS X and there are plenty of examples (not only the official examples, but many more).


if it’s useful the install scripts in scripts/ci/linuxarmv6 & 7 create an RPI image that can be used to cross compile any OF application. including downloading a compatible toolchain