CLion 2019.3 EAP: Ninja or Another Generator of Your Choice in CMake


A new CLion 2019.3 EAP (build 193.4697.8) is now available! Get it from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). A patch-update for anyone using the previous EAP build will be available shortly.


CMake remains the most deeply integrated project model in CLion. However, from the very beginning, we supported only the Makefiles generator. This limitation was caused by the fact that CLion was parsing the output of CMake command run with parameters such as -G “CodeBlocks – Unix Makefiles”, -G "CodeBlocks – MinGW Makefiles", or -G "CodeBlocks – NMake Makefiles" to get information about the project, which made it impossible to change the generator used.

This obviously caused some problems:

  • Ninja is known to be a much faster generator and is one of the most requested alternatives (CPP-2659).
  • With the Visual Studio toolchain, CLion was using something very similar to Makefiles – NMake, but the community expected Visual Studio CMake generators (CPP-14730).

As a solution, we considered supporting the CMake server first, but later found a better alternative – the new CMake File API, which was added by the CMake authors as a new and better way to query project information. And now, we are happy to present to you the new CLion 2019.3 build with this new API supported!

In practice, this gives you an opportunity to use any CMake generator of your choice!

Let’s look at the details.

How can I change the generator?

A very simple action is required to change the generator – just go to the CMake Profile settings in Settings / Preferences | Build, Execution, Deployment | CMake and pass the generator name in the CMake options, for example, -G Ninja:

After successfully reloading your project, you can see some similar output via the generation path:

This works for all platforms, remote mode, and the WSL, and for all generators supported by CMake (Ninja, Xcode, Visual Studio, and Makefiles). And you can use different generators in different CMake Profiles if necessary.

There are, however, a few things to bear in mind:

  • While CMake File API first appeared in CMake 3.14, CLion supports the feature only with CMake 3.15 or higher. (Currently, CMake 3.15.3 is bundled into the 2019.3 EAP builds, so you don’t have to install anything additionally, if you simply rely on a bundled version.)
  • Make sure you have the generator itself installed on your machine (like Ninja, for example).
  • Recompiling individual files is not supported in cases where the generator was changed as CLion can’t restore the build rules information easily (CPP-17622).

How do build type settings work for multi-configuration generators?

Xcode and Visual Studio are so-called multi-configuration generators, which means the project files for all build types will be generated by CMake. However, CLion will only use the build type specified in the CMake Profile settings for indexing and the actual building (in the build command line arguments, you can find the proper config is passed by CLion, for example: –config Debug).

That’s it for today! The full release notes are available here.


Your CLion Team
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , , . Bookmark the permalink.

71 Responses to CLion 2019.3 EAP: Ninja or Another Generator of Your Choice in CMake

  1. Taw says:

    Strange, I did not receive any notification email, like I used to.
    Question: is the “IDE slowness” fixed (IDEA-224636)? I cannot determine, because there so many issues linked to it and I cannot find it in the changelog.

    • Anastasia Kazakova says:

      Notification email is on the way) You are just too quick.

      yes, should be. We are still trying to test is properly on our side, but if you can check it for your case and report the state in the comments to the ticket, we’ll greatly appreciate your help.

  2. Roman says:

    Fantastic! Instead of waiting 10 seconds each time, now it just prints “ninja: no work to do.
    ” and launches immediately!

    Hopefully CPP-17622 can be fixed, I’m surprised CMake does not supports it.

    • Anastasia Kazakova says:

      That’s not about CMake. There is just no clear way to understand what were the actual build rules for the file. When only one generator was allowed, it was clear enough, but here the story is much more complicated. Feel free to upvote the ticket if you consider it really important for your workflow.

      • Dmitry Nezhevenko says:

        Could you please at least add some way to provide command to compile single file? Something like ‘ {filename}’?

        PS. Most likely you can use compile_commands.json for this

        • Anastasia Kazakova says:

          This might be a way to resolve it, but it definitely requires an effort. Please upvote the ticket. BTW, what do you use it for usually, just to check that the compilation of a single file is ok?

          • Dmitry Nezhevenko says:


            Yes. Usually it’s used to avoid rebuilds (or heavy linker calls) when editing code.

            PS. I really like this feature for header files. CLion tries to find related cpp file that includes header file and compiles it. It saves a lot of time when editing general headers.

            PPS. I would also like to see ‘preprocess file and open result’ in editor. I know that it’s very compiler-specific..

          • Anastasia Kazakova says:

            Thank you for the explanation!

        • Pavel Samolysov says:

          If I right understand, the feature exists in the Intellij Bazel plugin (bridge from the IntelliJ products including CMake to the Bazel build system): you can compile a single file even a header one and all Bazel targets where the file included in srcs or hdrs will be rebuilt.

  3. Roman Popov says:

    Looks like it does not work on Windows. I see .cmake file API directory, but Clion shows no targets. Trying to run “Build Project” ends immediately with “Cannot find any Cmake profile”

    • Miha Rozina says:

      Same for me. Also if I use Visual Studio toolchain and Ninja generator, Ninja finds gcc compiler instead of the Visual C++ compiler set in CLion.

      • Anastasia Kazakova says:

        Could you please check, when you build which CMake profiler is selected in the switcher in top right corner? Is it a CMake Profiler with the VS toolchain? Could you please show the compilation command CLion invoked for that case?

        • Miha Rozina says:

          Unfortunately I cannot build anything because I cannot select the CMake configurations with custom generators (same problem as Roman Popov above).

          However the CMake configure command still runs for all configurations. This is the command CLion runs: “C:\Program Files\JetBrains\CLion 193.3519.24\bin\cmake\win\bin\cmake.exe” -DCMAKE_BUILD_TYPE=Debug -G Ninja C:\
          This is for Visual Studio toolchain with Ninja generator.

          And this is the result:
          — The C compiler identification is GNU 8.1.0
          — The CXX compiler identification is GNU 8.1.0

      • Markus Böck says:

        This is due to cmake not knowing which compiler to choose. Just also specify – DCMAKE_CXX_COMPILER=cl.exe and likewise for C

        • Anastasia Kazakova says:

          CMake Profile is using the VS toolchain and the toolchain should know the compiler. You can check which compiler is in use in Settings | Build, Execution, Deployment | Toolchains | VS toolchain, which should be selected for the dedicated CMake profile.

    • Anastasia Kazakova says:

      Could you please try Tools | CMake | Reset Cache and Reload Project? If still doesn’t work, then we probably need some more details to investigate the case as we can’t simply reproduce it on our side.

  4. khancyr says:

    Very nice ! It works for me on linux.
    A nice addition would be to have an option on Settings to force output coloration on Ninja !

  5. Wiktor Żurawik says:

    Fantastic update. We had a special plugin to support XCode CMake generator, however, this feature will take that weight off our shoulders. :) Thank you.

  6. Sanny Sanoff says:

    This is great! Works with Ninja (linux, had to remove build dir) ! But to appreciate it fully, we need another easy improvement.

    My (any i think mostly anyone’s) workflow is “change/compile/run”. So what happens is I changed few lines and then I press run. It begins to compile. But at the same time, 90% of CPU is eaten by background code analysis. You know, that CIDR stuff. I have all my cores filled with:

    at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTable$1Builder.process(
    at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTable.processFile(
    at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTable.processSymbols(
    at com.jetbrains.cidr.lang.psi.impl.symbols.OCFileGlobalSymbolsCache.processFileImpl(
    at com.jetbrains.cidr.lang.psi.impl.symbols.OCFileGlobalSymbolsCache.processFile(

    it’s eating all cores for good 15 seconds after each little change in file (even adding empty line between methods), so compilation is slowed down noticeably.

    Easy solution: could you enable option to stop analysis if compilation is launched?

  7. Martin Pecka says:

    My Jetbrains Toolbox on Windows reported this new version and installed it automatically, but the linux one doesn’t know about this EAP version. It shows 193.4386 and no updates available. And I have the EAP installation enabled, and the toolbox had already installed a few EAP versions on this machine.

    • Anastasia Kazakova says:

      193.4697.8 is the latest build. Probably, your Linux is already updated (maybe automatic updates are enabled).

  8. Robin Thoni says:

    I’ve been waiting for this since 2017, THANK YOU!

  9. Kevin Bro says:

    Make sure that the configured toolchain does not have a make executable set, otherwise ninja will not work!

  10. Roman Popov says:

    Is it possible to add existing build directory to Clion? In a company I work for build is automated with gradle : it builds all project components written in various languages. For C++ sub-projects it uses CMake with ninja generator. C++ build takes 10 minutes. Currently I have to run it twice : one time with gradle, and one time in Clion.
    It was not possible before, when Clion only supported makefiles, but now since you have Ninja support, can I use existing build instead of creating new build directory from Clion?

    • Anastasia Kazakova says:

      Now not, it was working for build directories with Makefiles generator previously, but now the task became more complicated, as now more than one generator is allowed. However, it might be a good feature to put back. Please create a feature request with your use case description. Thanks

  11. Pavel Král says:

    Does it mean that files navigation may now respect project model context as described in ? Thank you.

  12. Martin O'Shea says:

    This definitely has moved my CLion satisfaction needle in the right direction, good job CLion team :)

  13. Olof says:

    I’m excited to try ninja, but alas, I can’t.

    OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.

    (process:10878): Gtk-WARNING **: Locale not supported by C library.
    Using the fallback ‘C’ locale.
    WARNING: An illegal reflective access operation has occurred
    WARNING: Illegal reflective access by com.intellij.util.ReflectionUtil to method sun.java2d.SunGraphicsEnvironment.isUIScaleEnabled()
    WARNING: Please consider reporting this to the maintainers of com.intellij.util.ReflectionUtil
    WARNING: Use –illegal-access=warn to enable warnings of further illegal reflective access operations
    WARNING: All illegal access operations will be denied in a future release

    I’m on Centos7

  14. JSZ says:

    Thanks for adding Ninja support! There is an issue with it though, that certain targets cannot be built from within CLion but build fine with Make. From what I can tell, usually targets that call a Python script suffer from this issue. If I hit ‘Build’, it will open the ‘Edit Configurations’ dialog with that target selected and a red X mark appears in the corner of the target. I can still build such target from the command line using ninja just fine. Could this be looked at?

  15. ilya b says:

    First of all, thank you for the long awaited Ninja generator feature!

    I had an issue setting it up, but I worked around it pretty quickly

    My setup:

    – Bundled cmake (3.15.3)
    – ninja is built locally and linked in /usr/local/bin/ninja

    Before I made any changes to CMake settings, the command line for recreating the project was

    “/Applications/CLion 2019.3” -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=/usr/bin/make -G “CodeBlocks – Unix Makefiles” /…/my/project/path/

    After I added -G Ninja it became

    “/Applications/CLion 2019.3” -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=/usr/bin/make -G Ninja /…/my/project/path/

    As you can see, -DCMAKE_MAKE_PROGRAM=/usr/bin/make is still present. This makes CMake think that make binary is Ninja, leading to a failure during project file generation

    Then I changed my CMake options to

    -G Ninja -DCMAKE_MAKE_PROGRAM=/usr/local/bin/ninja

    This prevents CMake from seeing an incorrect binary, which is still present in the command line CLion attempts to execute

    “/Applications/CLion 2019.3” -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=/usr/bin/make -G Ninja -DCMAKE_MAKE_PROGRAM=/usr/local/bin/ninja /…/my/project/path/

    As you can see, -DCMAKE_MAKE_PROGRAM appears twice, however, the latter is taking precedence.

    After this change, Ninja build works fine.

  16. Roman Popov says:

    How I specify build command? Need to run Ninja build with Incredibuild.

Leave a Reply

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