Are there any plan for supporting CLion?

Hello, I want to know if there are any plan for supporting CLion which is the C++ IDE developed by JetBrains.
It seems very great IDE, so I think it is worth considering.


1 Like

I don’t think there are any official plans, but you’re welcome to give it a try.

Currently we support 2+ build tools / IDEs for each of the Win/Lin/OSX platforms supported by CLion.

for posterity: I just came across this.

1 Like

For info, I succeeded to make it work on Linux 64 with CLion 1.2 adapting the cmake file from the github.

Can you post so I can see :slight_smile: ?

I have been working on updating this for oF 0.9, and have come dangerously close to complete success with OSX 10.11 and CLion 1.2.

I’ve forked @ilmenite’s ‘44a’ branch of @kureta’s cmake with the updates. Everything seems to work for me except native GL calls, like glPushMatrix(). Real bummer because ofxDatGui’s color picker relies on native GL sampling, but 10 hours of fiddling have gotten me no closer to success on that front.

My fork here:

If anyone knows how to get the GL functions linked properly, please chime in!

@kureta and @ilmenite – Should we consolidate these under one repo with different versions for different oF releases? This is my first time attempting contribution to an OSS project, so please forgive me if I’m hazy on the etiquette.

I would be happy to help in any way if I can. I did not contribute to any opensource projects before either, so it will be fun :slight_smile:

Hey @kureta and @SFBurning,
Let’s try to incorporate the CMake files into the project generator. We will have to support multiple versions (at least 0.8.4 and 0.9 for now).

@SFBurning, do you want to take a shot at patching the project generator? You would need to fork this repo here:
Multiple CMake template files can be maintained for different versions of oF (thereby removing the need for branches or different repos).

@PPilmeyer, could you link the CMake file for Linux? Initially, we should support Linux and Mac.

@kureta, I believe the CMake file can be made recursive to include all headers, rather than including each one separately. Could you take a look into this optimization? The simpler the CMake file gets, the better.

Additionally, if somebody has any IntelliJ plugin development experience, or is interested, could create an oF plugin for CLion.

@ilmenite I have been looking at CMake docs and they are discouraging recursion because if you use it the build system will not know when a single file has changed. But I will look into it. Also a single CMake file should be enough as it is a very comprehensive build system. Everything about the OS (Mac or Linux), oF version, etc. can be built into a single CMake file.

@SFBurning do you generally need to access system frameworks other than OpenGL. Because I fixed the GL functions problem but if you try to access other system frameworks theyt will also give a similar error.

@kureta, awesome! So you could support Mac and Linux with one file for different oF versions.

Also, I was referring to having the oF headers recursively included, since they won’t really be changed.

What would be the proper way to get the current oF version by looking into its files. The easiest way I found is to check the first line of but I am not so sure that it’s a good idea.

Perhaps a header file check? The change log might change formats at any time.
There’s bound to be at least one header file added in every version.

What do you think?

I have just found this file: “libs/openFrameworks/utils/ofConstants.h”

#define OF_VERSION_PRE_RELEASE "stable"

I guess this is our best bet.

I have another proposition now. Using the current CMake files clutters up the workspace. All oF files are listed under the project now. I think we should create an independent CmakeLists.txt for openframeworks and make it compilable as a library, then we should include it in our Application using ExternalProject functions. So openFrameworks will be listed as an external library and our workspace will be neat and tidy.

What do you guys think?

Yes, that actually works well in terms of organization.

@kureta, we also need a way to include addons. The way I’m thinking about this is - have a predefined variable in the project cmake file, which can hold space separated addon names.

Then the main oF cmake file, if this variable is non empty, will recursively add the addons to the project.


Directory structures of addons are not so standard. So it is easier and safer to create an addon_config.cmake for each addon. I have created a new repo for this divided approach. You can see the directory structure. Just copy files into their respective directories and test it with opencvExample application please.

Everything is a bit messy, I have to standardize variable names and uppercase/lowercase stuff.

the repo

Addons have pretty much src in their root (most of them at least). I’m saying this because not all addons published will have the cmake counterpart (looked at the way you’re currently including an addon in your repo).

It’s got to be easy for a beginner as well. Hence the automatically include stuff in src/ for an addon (if available, else print some warning).

I’ll test it shortly, and get back.

Can you add some support for 0.8.4? Can’t get it to compile, but CLion has recognised the project correctly, and added the dependency too.

src part is not the problem, the libs part is.

For example ofxOpenCv has a library inside. You have to add ofxOpenCv/libs/opencv/include and ofxOpenCv/libs/opencv/include/opencv to include_directoriesbut not ofxOpenCv/libs/opencv/include/opencv2.

There are also sources in these directories but they should not be compiled. Instead the library should be loaded from ofxOpenCv/libs/opencv/lib/osx/opencv.a.

Whereas ofxOsc has a libs directory with a completely different structure and its library has to be compiled from source. ofxOsc/libs/oscpack/src/ip and ofxOsc/libs/oscpack/src/os

Also some of the addons have windows/linux specific libraries. So most of them may be similar but they do not all follow a simple template. We can try and write a cmake file that will handle every exception but it would be the same as writing them individually, and harder to maintain. Also it would not work with third party addons and the reason might not be obvious to the user. If we use addon_config.cmake for each addon they will now their third party addon also needs one of these files.

Got it, the current approach is perfect then. If the addon doesn’t have a cmake file, then it’ll break the build.