Quickest way for project setup with OpenFrameworks?

Hi there, I used OF in the past and kinda liked it, now i’m coming back to it, but the project setup was always very cumbersome.

I would like a way to very quickly get a project set up in a Github repository, in the best case with CMake support because anyone should be able to develop with any IDE. I saw a github repo providing CMake support, but it is still not very polished.

In the best case you should be able to create a new project with a single command, and then anyone should be able to clone, generate and build it, with any IDE, on any operating system.

Is there something obvious already available that I am missing? Otherwise I might do it myself (based on the CMake addon) and release it as an official single-command project setup template, but I don’t want to reinvent the wheel if it already exists…

1 Like

There isn’t any CMake support for the current version… but I agree it would be great, for easier distribution of the source code, and easier use with other code editors!

I’ve recently worked on a simple sh script that would download the nightly for your OS, and place it in a libs folder. And then used Make to build for linux and macOS

Alright, that’s what I thought. I am absolutely a fan of source builds (provided that they work out of the box :grin:), which is why i’m currently developing a Github repo with CMake support. Unfortunately most of the dependencies are kind of ancient and exotic and therefore don’t provide CMake support either.

When my template is finished you can create a new project by using the Github Repository Template feature and when cloning you just call CMake and the project files for your IDE are automatically generated as needed.

It will use CPM.cmake, a package manager embedded completely in cmake, this means you only need cmake and git installed on your pc (which almost everyone has) and when calling cmake it will automatically download all the dependencies and build them from source and link them.

It will take a bit of time to build, but it’s all only a single command. The only real downside of 100% source builds is the build time, but this is only the first time you build it. The advantages are countless.

What do you think?

Oh and it’s going to be a bit of a hack to use CMake for the OF library which doesn’t have support for it itself, what about merging the CMakeLists into the official OF repository instead of keeping it in a separate template? Then everything would be clean and official and any project could easily include it through CMake… ?

Hi, Just use the Project Generator. If someone else wants to use your project they would need to use OF as well so they will have the project generator too. I think that the CMake stuff is overkill but if you want to go that way I am no one to tell you not to. If you develop some CMake script make sure you share it :slight_smile:

I think it exactly the other way around :slight_smile:

What you said wouldn’t really work since the entire folder is made for one compiler and so you’re tied to this one compiler forever. And sharing only the apps folder is a really bad idea IMO. Doing this is of course perfect if you just want to tinker around and you don’t care about anything else. The way OF is currently set up with the project generator is perfect for anyone that is just trying to get anything to work on their machine, and as soon as it works, they are happy.

On the other hand, it doesn’t work well at all for long-living professional open-source project that anyone can build and contribute. That’s what I am trying to change.

Currently you have openFrameworks encompassing your projects, but that’s really strange if your main point of interest is your project. Instead (for such a publicly available project) it makes much more sense to turn it around and have your own project be the root, and it pulls openFrameworks as a dependency. It’s a lot cleaner and opens a lot of doors for future expansion.

The only ‘downside’ to that is that every project is isolated and has it’s own copy of OF, but that’s not a downside as that’s exactly what you want: Encapsulation. For small projects for tinkering: No. For large, public, professional open-source projects like desktop apps? Yes!


Hi, I understand what you mean but that is actually not correct. you can have your project sitting where ever you want to on your hard drive and have the openFrameworks folder where ever else. And you actually can have the Project Genereator elsewhere. When you use the Project Generator you only need to make sure that it is setup pointing to where you have the OF folder and then you open in it your project and it will create all the necesary linking and etc, pulling OF as a dependency as you said. You can also have addons sitting wherever, in the addons.make file you can use a path relative to the project or as an absolute path and it will work as well.
As for generating a CMake project file, I recommend you to look at the Project Generator source code itself and add a class for generating the CMake file.

I see, you can change the path to the library in the project generator which means it could probably be set relative to the root, in a subfolder.

But that means the project files are still generated for Visual Studio only, right? Or can you generate multiple IDEs in a single app folder? I would assume that when you generate for Visual Studio, the app folder contains all the VS files, being incompatible with other build systems at the same time, and the OF framework dependencies are also VS only, right?

I am not sure if it works with a relative path. I have not tried like that.

PG can generate projects for multiple IDEs in the same app folder. In PG´s configuration (the gear icon at the top right) choose advanced options and there you will be able to choose which IDE project you want to generate. Then just change the project type and click on generate.

1 Like

Thanks, i might investigate that when i have time to get back to OF

@HerrNamenlos123 just to mention: it is indeed a good practice to store and maintain your project code outside of the OF tree (by default it gets placed into apps/ but it’s only a convenient starting point).

just editing the relative path works well in QtCreator as it re-parses the whole project upon changes to the .qbs; does not really work in Xcode because of hardcoded addons relative paths that depend on a specific “distance” from $OF_ROOT. don’t know about other environments.

in all cases PG will rewrite the whole project; some environments can coexist while others compete (for instance an iOS project will get mangled if you generate a macOS project in the same directory). but in essence you can switch from different versions of OF without touching the app code. i find myself doing that now and then between my github OF repo and a binary release.

the idea is that you only need to hold onto the app’s src/ folder (and perhaps bin/data/ if assets are required), and can re-generate the project for any version of any platform (you can look at the examples directory on github; there are no IDE projects there they get generated as releases are produced). [edited to add: for perennity, of course also hold a copy of the OF+addons as they where at the moment of development, but it does not need to be within your own project history.]

it’s also sometimes becomes required if the project format evolves (Xcode tends to need that every few years, as an old Xcode project might no behave well into a recent version of the IDE).

(NOTE: re-generating a project wipes any changes that you may have manually made in the IDE project file. if you have advanced/fancy recurrent project-level needs (that are not inheritable from an addon_config) you can prepare your own template and instruct PG to base it’s work on your’s)

@roymacdonald i agree CMake may be overkill, but (a) the OF Makefile hierarchy of PG+OF is not exactly limpid and could actually be simpler in CMake and (b) a Cmake harness with addon hooks would be a boon to maintain cross-platform addons (and would gain Conan support, amongst other facilities).

I have no experience with Xcode or QtCreator, so I can’t say anything about that.

But i do not think at all that CMake is overkill, it’s the opposite. It is exactly what OF needs. CMake is even advisable for very small projects with a single file and the bigger it gets the more important a proper build system gets.

Makefiles (or at least writing them manually) is absolutely deprecated. You can achieve the same thing with CMake with 10 times less code and it works out of the box on any platform.

If you have proper cmake support, everything would be easier. It would find system packages, dependencies, link them for you, build all the files, install them into your system in an installation directory and i recently learned that you can even create installers for any platform using native cmake. Installers for distributing OF applications is currently entirely unsupported, right? With CMake it could be done with a single command, building installers for windows, and deb, rpm and dmg packages for any unix systems. Out of the box.

Seriously, I don’t quite know how you package OF in the github releases (where you’re getting the precompiled binaries from), but if you had cmake you wouldn’t need any of that. It just works on any system.

It wouldn’t even change the project generator a lot. If you insist on keeping the project generator, it could still be used with CMake. There could be an option that generates a CMake project that has the opposite structure as usual, so it would generate the project root as the root, in any external folder, and includes a CMake file that then pulls OF as a dependency and links it. It can even automatically download the dependencies.

Also, there are no absolute paths whatsoever. As @burton said, it opens many many many doors for other projects, build systems, and even a package manager like conan. How lovely would it be to have OF in Conan… On the other hand the only doors being closed are weird Makelist errors and linking errors. Additionally it’s quite important for Continuous Integration. If OF has that at all, it would make it 1000 times easier and CMake could do ALL of the packaging and releasing work and even create a nightly build for github releases, with all dependencies included. And for the end users, it’s just 3 additional lines to bundle everything into an installer so you can distribute your app.

I do not even want to sound like i’m just praising CMake, but I think OF is seriously missing any proper build system. The code is there but it can’t be built easily. Without offending anyone, I get the feeling you haven’t worked with a proper build system before and do not know how easy everything could get :slight_smile:

Just to be sure, did you check the tooling in the GitHub project? GitHub - openframeworks/openFrameworks: openFrameworks is a community-developed cross platform toolkit for creative coding in C++. — there are different considerations between « releasing OF » for ~10 platforms, and locally building your own project that makes use of OF.

I do know that there is something like that, but I haven’t tried it myself. But AFAIK there is like an entire folder and multiple scripts for every platform, for initializing everything and downloading dependencies and it’s all very platform specific. As far as i know releasing is just copying a bunch of files together and is separate for every operating system. I would imagine this is one of the reasons releases are taking so long and there hasn’t been a new one since 1 and a half years if i remember correctly.

All of this is ideally done in CMake, you only do it once and it works automatically for any platform. Ideally packaging is also done by CMake (which is well supported) and it’s a single command to get your source package including dependencies, for a specific platform. Even cross-compiled. And in the best case if setup correctly you can even have all release packages for all platforms at the same time with a single command.

The idea is that it would ideally be done fully automated in a Github Action. No more releasing as it is done fully automatically on every branch merge or commit in the repository. But besides that is also helps for local development.

Yes, it CAN be done now too, but all the scripts are about 10 times more complicated than necessary and still very limited in compatibility.

I hope this is what you mean with OF tooling.

By the way, is there any sort of testing available? I haven’t found anything. In the best case you would for example let Github Actions compile all examples on all platforms automatically and thus you see immediately if there is any compiler error on any platform. Is there something like this available and I just haven’t seen it?

I just saw this thread:

If i understand this correctly, currently all sources including all addons are compiled in a single library and they’re requesting compiling addons into separate libraries to save time when they change. (although they shouldn’t recompile anyways so it shouldn’t actually make a difference i guess)

Another reason to use a proper build system. With CMake this would be a work of minutes. And it’s automatically done for every possible platform and IDE.
I’m going to keep this in mind and do that in CMake from the ground up.

I am trying to understand how the building currently works. Do I understand correctly that all dependencies are downloaded from GitHub - openframeworks/apothecary: This is the OpenFrameworks library apothecary. It mixes formulas and potions to build and update the C/C++ lib dependencies.?

Is this true for all different platforms or just some, like Windows?
And there are no other dependencies OF depends on, except the ones found in the apothecary?

Can someone please confirm my thoughts?

Hey @HerrNamenlos123 , you’ve likely already seen them, but there have been some efforts in the past to use CMake with OF. But just in case you haven’t, ofxCmake is one, and also on this GitHub page by Antoine Villeret. There are some threads in the forum about it too.

1 Like

Thank you, yes I know that these attempts exist. I will take a closer look at them when i have the time.

CMake would generate a “project” for a specific build system/ide, so the problem remains as how the addons are handled. Currently the addon’s source files are included into the project and compiled, just as regular source files, so it needs to compile, at least once, that addon for each project. What @elliotwoods suggests is that instead the addons are compiled into a static library which then when added to any project does not need to be recompiled.

apothecary is a script tool that is in charge of getting all the needed dependencies based on specific settings/scripts for each dependency. It works for all the OF supported platforms. All the dependencies are dealt with apothecary. Each of this scripts specifies the version of the dependency and where to get it along with the build instructions for that particular dependency and then some scripts to move what ever is needed to the place that is should sit. Why not relying on CMake? I am not sure, but I would guess that not all the dependencies actually use CMake making it not possible to include these. Just guesssing.

The nightly builds and the official releases dont need to run apothecary as the zip you download already contains those files. You only need apothecary when you want to update one of the dependencies.

So then there is a folder called scripts/templates in which you will find all the template projects for all the supported platforms. Then what project generator does is to grab this template, makes a copy of it which it modifies to add the necesary stuff from addons, etc. It does not generate the project from scratch.