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. https://cmake.org/Wiki/CMake:How_To_Find_Libraries
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.
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.
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!
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:
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: https://github.com/flvi0/openFrameworks/tree/feature-cmake-config
This project risen from its ashes here : https://github.com/ofnode/of (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 : https://travis-ci.org/ofnode/of/builds/160015301)