CLion 2017.2 EAP: CMake Cancel and more


A new CLion 2017.2 EAP is now available (build 172.2953.14).

C++ code analysis

CLion supports va_* macros in a more accurate way now. This means less false-positive code analysis, like for example, incorrect unused code inspection (CPP-9748).

Besides, CLion now works more accurately with GCC and Clang compiler predefined macros.


After optimizing the parsing of the compiler predefined macros in CLion, some performance improvement during the reindexing was achieved.


CMake reload can take significant time, and sometimes you decide to cancel when it’s already running (to introduce additional changes or just to postpone this time-consuming operation). It’s now possible in CLion – Stop button is available in the CMake tool window:
If you enable the auto-reload function, then currently running CMake command will be stopped automatically, in case you continue typing in CMake file, and the new one will be scheduled.

Besides, CLion now prints [Finished] in every output tab for each CMake configuration being reloaded and finished (not cancelled):cmake_finished

Check the full release notes here.

Download CLion 2017.2 EAP

Your CLion Team
The Drive to Develop

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

18 Responses to CLion 2017.2 EAP: CMake Cancel and more

  1. Roman says:

    It feels like Clion development pace slowed-down recent months. Is it really the case? Or you just working on some new features, that are not announced yet?

    • Anastasia Kazakova says:

      This release cycle was announced as mostly finishing some unfinished work, fixing bugs, working on performance, etc. For example, MSVC support, debug features, lots of fixes in C++ parser (and thus in code analysis). However, clang-tidy made its way to EAP, and some more big changes. Anyway, I guess it’s important for us to finish all the work that is already started before doing smth new.
      Besides, languages support improvements may not look as big changes, but require lots of work and resources.

  2. R3t says:

    Please work on performance! Clion on a relatively big project that uses libraries like boost, opencv… is close to unusable. It takes ~3-4 minutes Refreshing files after every build!! Why!?

    • Anastasia Kazakova says:

      Could you please check the memory usage? For this, go to Settings | Appearance & Behavior | Appearance | Show memory indicator and check it when you observe the issue. If it’s close to the limit, try to increase (

    • John Harris says:

      R3t I was able to keep CLion happy with a very large project by upping my
      Xmx to 5000m. Also, I’ve found it helpful to “Invalidate caches/restart” periodically,
      especially after large external source changes (e.g. git checkout or rebase).


  3. Newt says:

    I hope you guys remember fixing (and adding) features for refactoring, navigation and generation of code. For a c++ coder like myself, these features are really (!!) important.

    Yes, we also need cmake functions, debugging, etc. But, these features don’t make c++ coding more efficient.

    I urge the CLion team to make c++ coding as efficient as java coding is in IntelliJ!!

    • Anastasia Kazakova says:

      Thanks. Of course, we do care about it. C++ support experience is our top priority. That’s why currently we are busy with some global improvements in the C++ parser. For the end user that means less false positives in code analysis, more accurate refactorings, etc.

      • Olof says:

        This is great news!!!

        I can’t wait!

      • Juraj says:

        Hi, I have a suggestion/question about false positives (you’ll probably redirect me to the issue tracker). Is there an opt-in option to contribute information about false positives? E.g. the project successfully compiles, but there are some squiggles in CLion, suggesting that its parser thinks that the project should not compile without errors. In these situations, you could (of course, with prior agreement of the user) automatically collect data about this.

        • Anastasia Kazakova says:

          No, this is not possible for now.
          Actually, not many of our users are ready to share the full project and even if they do it sometimes hard, as such projects might require lots of additional libs, environment configuration, etc. So simple sample to reproduce the issue is always an easier way to go, however, we can’t easily pick it up automatically.

      • Newt says:

        Great! I am impatient because there is so much potential :)

  4. Olof says:

    I had a thought the other day. Apologies if this is already happening or if it has been tried but with no effect.

    Have you considered lowering the priority, or “niceing” the compilation? This will likely add a minimal amount of time to the compilation. Compilation needs high throughput but not low latency.

    I have what is called 32 cores in my server, but that is with hyper threading and is a bit of a marketing move. A system with 32 cores with hyper threading is about 10% faster than a 16 core system without hyper threading. The second thread on a core can only run if the other one is blocked. At least that used to be true when hyper threading was introduced.

    So, for the sake of argument, let’s say that I have set -j 16 for number of cores to use for compilation and that the compilation is such that I have one compilation process going on each physical core (of which there are 16). Now, when CLion needs to do something the OS will need to place the CLion thread on one of the cores that already has a compilation going on and this is where hyper threading comes in. Simply put, the one (I’m guessing) GUI thread is going to get what amounts to about 55% of that core and will be subject to the whims of the scheduler. I would gladly make my compilation a bit slower if it meant that the GUI was snappier while compiling.

    I’m not sure if this would make a bigger effect on a system with many cores or just a few.

    It might also be worth it to set aside a core or two from the compilation for the default number of compilation threads (which is the same as the number of cores and for me is 32). At least on systems with a lot of cores this might be reasonable. I’m going to set that to 30 tomorrow, come to think of it.

    I follow the red/green/refactor methodology which means that I’m almost always compiling.

    This might be a simple way to make things feel a bit snappier.

    • Anton Makeev says:

      Olof, sounds reasonable; though it’s hard to find a value that ‘fits all’.
      We’ll lower the number to something reasonable in

      • Olof says:

        Thank you. Any thoughts on priorities or nice settings for the compiling?

        • Anton Makeev says:

          What do you mean?

          • Olof says:

            I meant that the gcc or clang processes could run at a lower priority or nicer nice value so that the compiler nicely steps aside when someone else, such as the CLion GUI, wants to do something. I think that might be even more important for responsiveness than reducing the number of cores used for compiling.

            Lowering the priority for compilation should not affect the performance much because for the most part CPU’s are idling. So when the GUI needs a millisecond one of the 32 cores that compilation unit will let the GUI run. That way you can also have more cores compiling than cores/2 as noted in the YouTrack while still having a responsive GUI. Maybe something like cores – 10% or something.

            I looked earlier and I think that my compilation runs at the same priority as the GUI, competing with it.

            I think that maybe one thing that people don’t think about much is the vastly different compilation speeds between let’s say Java and C++. So the time that the IntelliJ GUI has to compete with the java compiler is much much less than the time CLion has to compete with gcc or clang. I’m guessing that maybe 5% of the time that I use the CLion I’m also compiling in the background.

            So, I guess the shorter way to phrase myself is that it would be great if there were ways to make the GUI more responsive while compiling in the background.

            Maybe indexing could be made less intrusive by running with lower priority as well.

          • Anton Makeev says:

            I see. We don’t have mechanics atm for that, but anyways, here is the ticket:

          • Olof says:

            As a workaround for the compilation, as opposed to the more general case in the YouTrack issue, to try this out I created a small shell script file that I call to my path.

            nice -10 make “$@”

            Then I added this cmake command line definition in settings:

            I’ll try this for a while to see if it makes a difference.

Leave a Reply

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