All systems are go: CLion 2017.2 roadmap


It’s been a week since we released our first big update this year – CLion 2017.1. We’d like to thank you all for your warm welcome and useful feedback. If you haven’t tried it yet, do it today! There are lots of goodies like C++14 and some C++17, disassembly view, Microsoft Visual C++ compiler, Catch and many more.

All systems are go, and we’re moving on to 2017.2.

Special thanks

To follow a good tradition, let us first thank those who helped us in the early stages as we ran the 2017.1 Early Access Program. We’re rewarding the following contributors whose input was the most valuable in this release cycle:

  • Andrew Somerville (Twitter handle: catskul)
  • Rohan Joyce (YouTrack handle: rfjoyce)
  • Jean-Marc Bourguet (YouTrack handle:
  • Matt Godbolt (YouTrack handle: mattgodbolt)

In appreciation of your efforts, we present you with a free 1-year subscription for CLion (to extend your current subscription or get a new one). Each of you will receive a personal email with details on how to claim your license. (If for some reason you do not get any email from us within a week, ping us here in the comments.)

What you can expect from CLion 2017.2

After analyzing the feedback and the current state of CLion, we’ve decided to dedicate the upcoming release to various fixes, cleanups and improvements to current functionality. That doesn’t mean nothing new could finally join the release, but our focus will be shifted more into this direction.

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2017.2.
  • C++ support
    • Continue with C++17. Check the list of supported language features in our webhelp
    • Fix false-positives in code analysis, which are mostly caused by incorrect code resolve
    • Modernize code transformation actions (like code generation or some intentions) so that modern C++ standards are in use
  • Microsoft Visual C++ compiler support
    Started as an experimental feature in 2017.1, this will be evaluated and get wider adoption in CLion:

    • Microsoft language extensions support
    • Support for precompiled headers (that currently works for GCC and clang)
  • Debugger
    • Continue working on the disassembly view in debugger:
      • force step into action (CPP-8978) to avoid jumping into the disassembly when not expected
      • disassembly view for LLDB (CPP-8908)
      • disassemble on demand (CPP-9091) to cover cases when the sources are available, but the disassembly view is still required
    • Hex formatting for numerical variables (OC-2305)
    • Debug as root (CPP-7224)
  • Project model
    This is still going to be CMake. Please see the section below explaining our plans regarding other build systems. In 2017.2 we will mainly address the following:

    • Make toolchains settings configurable per project / per configuration (not per IDE as it is now). This will cover environment, CMake settings, compiler, debugger, etc. (CPP-8893)
    • MSYS support (CPP-2275)
  • Performance
    Unfortunately it’s hard to promise something specific here, but we 100% sure to dedicate some additional time to this task. Our current plan is not only to continue working on investigating user-submitted snapshots, but also to implement a set of index and other optimizations.
  • Others
    Other planned tasks include fixes related to unit testing (for both Google Test and Catch), macro formatting, fixes for some current issues with the Python support plugin, and more.

Looks like we’ve packed quite a lot here, so let’s see what we can really achieve until July or August, which is when the actual release is planned.

No makefiles?

Sorting the tickets in our tracker by votes, we find some clear winners – Makefiles and remote toolchain support. As you’ve been asking about our plans on these, we’ll address them here to make our planning process clearer and explain our choices.

The immediate answer, as you can see from the roadmap, is No. We are not planning any of these task for 2017.2. However, the eventual answer is Yes… after we resolve some other issues.

Let’s talk about Makefiles. It all boils down to the experience we would like to offer to the users of CLion. Originally we made the choice to use CMake as a main project model and we believe it was the right decision. Thanks to all the help and support from our community, we’ve made huge progress since then. But we are not yet satisfied with the level of support and usability of CMake integration and would like to improve it, before we move further and add support for Makefiles and other build systems.

The major planned CMake improvements are:

  • Ninja generator support,
  • configuring CMake defaults,
  • canceling CMake generation process.

This will also be considered for 2017.2 and 2017.3.

Also, since one of CLion’s main strengths is being a cross-platform IDE, we would like to offer Windows support on par with Linux/macOS. That means CLion needs to work with Microsoft Visual C++ compiler as effectively as it works with GCC or Clang. We already started working on this, and will continue to do so in the next release cycle.

Implementing Makefiles support will require additional work around the project model and indexing. Since Makefiles do not directly list headers, first we need to find a solution for problems related to non-project headers (CPP-263, CPP-270).

These are the main tasks we would like to finish before implementing Makefiles support, though there might be additional smaller ones. Since we cannot predict how long they will take, we can’t give you an ETA. But please rest assured that Makefiles is on our radar and we believe it will be an important addition for CLion as a cross-platform C/C++ IDE.

This is it! Stay tuned and don’t miss the EAP launch for 2017.2.

Your CLion Team

The Drive to Develop

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

44 Responses to All systems are go: CLion 2017.2 roadmap

  1. Sebastian says:

    Do you have any plans to support ctest?

  2. Alex says:

    Have any plan for support QML syntax?

  3. Jan Svoboda says:

    After reading the first sentence under “No makefiles?” I was expecting few words on remote toolchain support. What are your plans on that? Can we expect some progress on this in any of 2017.x releases?

    Thanks for the great IDE!

    • Anastasia Kazakova says:

      Thank you for your support.

      Taking into account the amount of work planned and urgent tasks around performance and project model, remote toolchain most likely is postponed for now. We’ll try to take a look at the possible options and maybe consider some solution, but very unlikely in 2017.2.

  4. D Fly says:

    Hi Anastasia,

    You guys have made a great product, thank you for all of your efforts!

    I’m surprised to hear that supporting Visual Studio as a toolchain is so high on the priorities. The people I know who work with Visual Studio think its the greatest thing since sliced bread and wouldn’t give it up for the world.

    Personally, I would have thought that supporting the “Ubuntu on Windows” toolchain was a no brainer. That environment has been a cygwin-killer for me, and I only keep cygwin around for CLion at this point. But I’ll keep waiting!

    Again, thank you for all of your hard work!

    • Tano says:

      I totally agree, no one who uses VStudio will switch to CLion, but for Linux CLion is the best.

    • Anastasia Kazakova says:

      As you know, MSVC was added without msbuild support, so if you have a VS project you still opens it in VS.

      However, we’ve chatted a lot with our customers and seems that many of them use MSVC to compile things on Windows on their cross-platform projects. So for them MSVC support in CLion was essential and necessary. That’s why we’ve added it.

      • D Fly says:

        Well, good. I hope you guys can snap up some market share with the Qt folks. I don’t use it, but I know many people do, and as far as I have heard, MSVC is the toolchain of choice for Qt on Windows.

        For those of us who are targeting Linux from Windows (many of the former Netbeans and Eclipse people, I imagine), you guys have a great tool. Just waiting for for the WSL/Bash on Ubuntu on Windows support … CLion is missing a great feature there. Hard to see choosing Cygwin over Ubuntu for Linux on Windows.

        Vote here, folks!

        Keep up the great work!

        • Anastasia Kazakova says:

          Thanks for your support!

        • Olof says:

          I had never heard of Ubuntu on Windows and was intrigued.

          And lo and behold, it worked out pretty great. I don’t know if I can use it for work, but in less than two hours I had CLion-2017.1.1.tar.gz running on Ubuntu for Windows using the XMing X11 server.

          It is looking a bit clunky, but I don’t think that’s CLion’s fault. The bundled cmake didn’t work, but I apt-getted cmake and even though that is version 2.8 it works. I also had to install gcc and g++. That’s version 4.8 which is ancient considering that I’m on gcc 6.3 usually. Last time I used apt-get it was on Debian Woody so I’m a bit rusty, but I’m guessing that there are ways to get newer version of those tools.

          First, here’s how you install ubuntu on Windows:

          Here’s a version of XMing:

          There are much newer versions available that probably are better but this one was easier to download so for this quick test I picked this version.

          After that was done there were a few things missing that needed installed on the Linux environment.

          $ sudo apt-get install x11-apps
          $ sudo apt-get install gcc
          $ sudo apt-get install libxrender1 libxtst6 libxi6
          $ sudo apt-get install cmake
          $ sudo apt-get install g++
          $ export DISPLAY=localhost:0.0
          $ &
          $ echo Booyah!

          I did a few more things as I was stumbling my way forward, but I think the list above is the stuff that mattered.

          Unfortunately this solution still uses X-Windows which is the bane of my existence. However, it might still be useful for those who don’t have a Linux server. Also, there was a few guys who posted recently who had to run CLion on their crowded build server and were being pressured to run Eclipse because it supports the remote tool-chain and maybe this would be useful for them as well.

          Also, while X-windows is the bane of my existence, maybe there is a way to run graphical applications in a different way through Ubuntu for Linux in the future or even now.

          • Anastasia Kazakova says:

            Yes, we were trying similar things here. And that’s make us think this could be a workable solution. We’ll consider it later.

        • Olof says:

          Oh, also, it said this:

          External file changes may be slow: File watcher gave up to operate

          in the event log.

    • Sky Schulz says:

      I’ve used VisualStudio for decades. I have 2015 and 2017 installed right now. With ReSharper++. I also have IntelliJ IDEA and CLion installed. I used them every chance I get.

      If I could get CLion to build for my target embedded system, I would switch 100% to CLion. However, I need msbuild support as a first-class model. Or 100% compatible generation via CMake.

  5. Olof says:

    Focusing on CPP correctness (including refactoring and generation) and performance is great I think.

    There’s a number of features that I’m drooling for but I’m biting my tongue because those two above issues are the only two things that I hear people around me complain about, and are honestly my main concerns as well.

    • Anastasia Kazakova says:

      Thanks for your support, Olof!

    • Roman says:

      Totally agree! Performance, refactorings, generators.
      Unfortunately nothing is working reliably now.

      • Anastasia Kazakova says:

        Please, make sure we know about all your issues so that we can put them to our queue. YouTrack issues is a preferred way. Thanks in advance!

        • Marcus says:

          I agree too.

          Code parsing has taken a huge leap forwards over the last few months (there are still quite a few parse errors – but it’s getting usable now)

          I’m really hopeful for Ninja support, C++17 and more parser fixes.

          Thank you Jetbrains.

  6. Tano says:

    I really don’t understand this: “CLion needs to work with Microsoft Visual C++ compiler”.
    CLion is great on Linux, I think it’s the best, but really it is no match for VStudio on Windows and the community edition is free. All big companies (for example gaming) use VStudio because it’s so fast compared to Java IDES (like Eclipse and CLion) and the memory used is like 25-50%.
    We tried to open the same huge project in VStudio, Eclipse and CLion and only VStudio could do it, the Java ones just stuck like 15 minutes.

    • Anastasia Kazakova says:

      As you know, MSVC was added without msbuild support, so if you have a VS project you still opens it in VS.

      However, we’ve chatted a lot with our customers and seems that many of them use MSVC to compile things on Windows on their cross-platform projects. So for them MSVC support in CLion was essential and necessary. That’s why we’ve added it.

  7. Martin Pecka says:

    What about Visual Studio project files? Then CLion could really become THE IDE :)

  8. Nestal Wan says:

    My company did not consider clion because it lacks remote compiler support. The standard IDE was NetBeans.

    There are just a few of us paying for clion ourselves, because it boost our productivity. We currently use remote X to develop Linux apps on Windows desktop.

    Because the Linux build server is shared by a large team, its resources is very tight. There is big pressure on us clion users to switch to NetBeans in order to save server resources.

    So if remote toolchain is not in clion road map this year, I am afraid I have to switch to NetBeans to keep my job. Clion is a much better IDE. It deserves every dollar I paid in the years. It’s a shame that I can’t use it anymore.

    • Anastasia Kazakova says:

      Thank you for your feedback.

      I understand the problem and really would like to promise something encouraging to you, but can’t estimate remote toolchain task for now. We’ll see if we can put it into 2017.3.

      • Nestal Wan says:

        Or you can reduce the memory usage. It helps my situation too.

        • Anastasia Kazakova says:

          Have you checked the memory indicator in your case? You can switch it on in Settings | Appearance & Behavior | Appearance | Show memory indicator. Is it growing or stable? You can also get a memory snapshot and share with us: We’ll investigate if we could reduce the memory usage somehow.

          • Nestal Wan says:

            Yes. It starts out at about 700MB. It will grow to about 2GB in a couple of hours of usage and stay there.

            Top shows about 11GB virtual and ~1.2GB resident.

            I will see if I can send you a memory snapshot when I have a chance.


          • Anastasia Kazakova says:

            Have you changes the default values for xmx for CLion? 2GB is a default.

            Could you also share with us:

            • Have I got you right that the sources are on Linux in your case, as well as all libraries, etc.?
            • Which compiler do you use?
  9. Olof says:

    I’ll bang the drum for this feature:

    I think it would be pretty easy to implement, and it would make cmake/CLion best IDE build system.

  10. Jean-Marc says:


    It seems to me that I have either not received your email or deleted it by mistake as I was catching up after some time out of the office.


  11. Marco says:

    Hi Anastasia,

    Is there a way to exploit CLion with a large makefile based project ?
    I mean not for building but at least for code browsing, retrieve call chains, class hierarchy, and auto-completion/suggestions.
    I tried to create a project by passing the root source code directory, but even after scanning all files for building the index, CLion is not able to resolve include directives, and so to resolve any symbol that is not defined in the local source file.
    Is there a way to make CLion retrieves and parses header files in a non-cmake based project ?

    • Anastasia Kazakova says:

      CLion relies on CMake project model heavily and takes all the information for code parsing and resolving from it. So in order to use your code in CLion you need to have some CMake project. You can try using Import Project that helps with creating some basic CMakeLists.txt. There is no other way for now.

Leave a Reply to Anastasia Kazakova Cancel reply

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