CMake vs. the others, round 1

Anton Makeev

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

Comments below can no longer be edited.

27 Responses to CMake vs. the others, round 1

  1. Edward Rudd says:

    October 2, 2014

    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:

      October 2, 2014

      Thanks for suggestion! We’ll have a look.

    • Matt Buse says:

      December 1, 2018

      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:

    October 4, 2014

    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:

      October 5, 2014

      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:

    October 9, 2014

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

    • Anton Makeev says:

      October 9, 2014

      In CLion you can find callees of a function using ‘Find Usages’ (Alt+F7 in the most of keymaps). Is that what you are looking for?

      • kurt says:

        October 10, 2014

        Yes, it beter than cscope. But clion run so slowly, maybe my PC is too old.

        • Anton Makeev says:

          October 10, 2014

          Is CLion slow in general or is it something specific?

          • kurt says:

            October 11, 2014

            General,My PC is more than 4 years aleardy

            • Anton Makeev says:

              October 13, 2014

              Kurt, we plan to improve the performance in future; so please stay tuned and let us known when you see any improvement or degradation.

  4. wl.nicholas says:

    October 10, 2014

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

    • Anton Makeev says:

      October 10, 2014

      That’s awesome! Do you think your plugin can help others with custom build systems?

      • wl.nicholas says:

        October 10, 2014

        I’m afraid not. It doesn’t support any public build system.

  5. Ronald Casetti says:

    October 15, 2014

    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!

    • Anastasia Kazakova says:

      October 15, 2014

      This wiki can help in terms of CMake variable understanding:
      Check the BINARY_DIR to see the generated Makefiles. The exact path can be found in CMakeCache tool window and will be smth like <...>/clion10/cmake/generated/<...>

      • Ronald Casetti says:

        October 15, 2014

        Thanks a lot! That’s exactly what I need.

  6. Loïc Prieto says:

    October 28, 2014

    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.


    • Anastasia Kazakova says:

      October 29, 2014

      Thank you. You are very welcome to try the EAP build and provide us your feedback.

  7. Shaun Edwards says:

    January 23, 2015

    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:

    February 17, 2015

    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…)

    • Anton Makeev says:

      March 5, 2015

      Trond, here is a corresponding request, but you can also do it by passing an additional compilation macro to CMake

  9. Dan Savio says:

    August 3, 2015

    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?

    • Anastasia Kazakova says:

      August 4, 2015

      Can you configure these in CMake files directly? Or pass as parameters in CMake options in Settings, in Build, Execution, Deployment | CMake section?

      Also we consider adding a possibility to run initial script to fill prj settings:

  10. Jason K says:

    March 29, 2016

    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:

      March 29, 2016

      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.


Subscribe for updates