CMake vs. the others, round 1

Hey everyone,

Yesterday we’ve published a new EAP build that allows opening non-CMake projects automatically; although this functionality is very basic and isn’t intended to recreate the full project description, it will help some of you try CLion on existing projects.

Today, we would like to share our thoughts on CMake with you and explain why we opted for it as a main project format.

When we were only planning a C++ IDE we had two options: either to invent our own build system or to reuse an existing one. For us the choice was obvious, since we wanted the IDE to be easily used with existing projects, we chose to go with some existing project format – a new one would inevitably hinder adoption; it would also require so much more work and definitely delay the release.

Having this in mind we looked for possible candidates for a build system; the criteria were popularity, maturity, availability on various platforms, ease of automation/integration in the IDE. I bet you can guess what the options were: make, Autotools, CMake, qmake.

Our brief research showed that CMake and ‘make’ were the most popular cross-platform tools, having ~30% of users each, while both Autotools and qmake had less than 7% of users. So we ended up with CMake and make; and at that point the ease of integration played the major role. If we chose ‘make’, we would have to write our own interpreter or devise smart tricks to get necessary project information from it. With CMake it proved pretty simple to get all we want, since during generation CMake produces lots of easily-parseable internal files containing vital info. Another advantage of CMake was its platform-independence – almost everything we needed is described in universal terms in CMake.
Yet another benefit, is that CMake is not a build system in the general meaning and doesn’t lock its users on one particular build system: users are free to use make/Ninja/etc to actually build the products; and that’s a huge advantage since neither build tool is suitable in all situations. Having projects description in CMake also allows the users to easily switch between IDEs.

Don’t get us wrong here, we are not trying to say that CMake is the best and the only tool and everyone should use it. These are, rather, our considerations that explain the choice. As we wrote earlier, we do plan to extend build tools support in future, but not very soon – it requires significant time, since every tool has its hidden peculiarities and challenges. For now we will focus on improving CMake support.

Meanwhile, take a look at the ‘Import Project from Sources’ feature and if you have suggestions, we are always here for a discussion.

Till next time,
The CLion Team

This entry was posted in Backstage and tagged . Bookmark the permalink.

27 Responses to CMake vs. the others, round 1

  1. Edward Rudd says:

    I’m super glad you chose CMake, as it is the best option out there and works well with cross platform projects.. I have projects (games) that use CMake and target Windows, Mac, Linux, iOS, and Emscripten all with a single set of clean CMake files.

    You should take a look at my cmake templates to see how I’ve added some extra functions to make CMake even easier to work with.

    • Anastasia Kazakova says:

      Thanks for suggestion! We’ll have a look.

    • Matt Buse says:

      I have been programming in Unix, Solaris, Irix, various flavors of Unix for over 30 years and I think Cmake is a fake product to hobble us programmers so somebody can have a “gateway” to controlling all projects. I don’t want to touch anything related to it but they seem to be winning. Same with Python, C++…all fake so some vested interest can control projects.

  2. Yewhen says:

    Hello, CLion dev team! Awesome work :) I have a question: why clion can’t support cmake version more than 2.8.x? (CMake: unsupported version 3.0.2 – when i try to set custom cmake executable)

    • Anastasia Kazakova says:

      Cause we haven’t had enough resources yet to introduce this support. Though we are planing to support upper versions in later updates.

  3. kurt says:

    Hi,I can’t find where a function was called, don’t have something like cscope??

  4. wl.nicholas says:

    never mind. I wrote a plugin using grammar-kit to convert our internal build system to CMake build files. :)

  5. Ronald Casetti says:

    Is it possible to extract makefiles made by cmake from Clion? It’ll be really helpful for writting cmake rules faster. For now I have to guess and do some “reverse engineering” to understand what every “magic” line in CMakeLists.txt means. IMHO cmake rules syntax is even worse than autoconf with all its ugly friends. There are lots of tutorials and examples how to write unbelivable cool and complicated cmake rules but nothing about ordinary every day cases.

    But anyway thanks for that awesome IDE! I fell in love with it when I saw the “Find usage” feature. Looking forward for the release!

  6. Loïc Prieto says:

    Hi there!

    I’m a year-long user of IntelliJ and I’m thrilled to try CLion. I’ve been wanting for a long time to start using C++ to make a game, perhaps CLion will provide a smoother transition with a familiar interface and the wonderful functionality you provide for the Java environment.

    Also, CMake seems like a good choice to me, in my ignorance of course.


  7. Shaun Edwards says:

    It does seem like CMake is powerful. Unfortunately IMHO the documentation is lacking. There are not enough real world tutorials. The “Mastering CMake” book is expensive and has a poor rating on Amazon. It has been quite hard for a me (a new C/C++ developer) to understand how to write a cmake script to build even a basic project with some external library dependencies.

  8. Trond Norbye says:

    It would be awesome if you could set a variable so that I could detect that it is being invoked from CLion (so I can provide sensible default values and skip stuff not supported by CLion yet…)

  9. Dan Savio says:

    Many times, projects are built with a script that passes lots of inputs to CMake to build properly. This then produces CMake cache files that contain all of those settings.

    Why can’t CLion read and open a project from those generated CMake files? This would allow someone to open a project right in CLion and build immediately. Today, I have to go to the CMake “Cache” tab and manually transfer all settings from my CMakeCache.txt generated file to the Cache in CLion for my project to build correctly. Is there a better way?

  10. Jason K says:

    I need to add my two cents. I’m evaluating CLion and am extremely frustrated by how it’s so half-baked and how deceptive your claims are.

    You claim to support CMake, but you don’t–you just read CMakeLists.txt files. Our CMakesLists.txt are complicated and FULLY describe each and every build. CLion barely understands anything in them.

    So, you need to stop advertising that you support CMake or that you use it “natively” because you don’t.

    (Realizing that you never set CMAKE_BUILD_TYPE cost me an hour of work. And, BTW, modifying the Cache is absurd–the settings are right there in the CMakeLists.txt file, just follow them and don’t require every developer to waste time. Even forcing me edit the CMakeLists.txt file directly for the parts you actually support is lame.)

    • Anastasia Kazakova says:

      We are really sorry you feel that way. Could you maybe share which CLion version you are using and probably some sample CMake? Feel free to describe your problems in details to our support ( and we’ll do our best to help – maybe it’s just a bug or we are lacking some features for CMake support, anyway we’ll try to address the issues.

Leave a Reply to Anastasia Kazakova Cancel reply

Your email address will not be published. Required fields are marked *