All systems are go: CLion 2017.2 roadmap

Anastasia Kazakova

Hi,

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: bourguet@cadence.com)
  • 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

JetBrains
The Drive to Develop

Comments below can no longer be edited.

44 Responses to All systems are go: CLion 2017.2 roadmap

  1. Sebastian says:

    April 6, 2017

    Do you have any plans to support ctest?

    • Anastasia Kazakova says:

      April 6, 2017

      There is a ticket (https://youtrack.jetbrains.com/issue/CPP-905) however no exact plans at this stage. At least not for 2017.2.

      We have some issues around Google Test and Catch (that are already implemented) that need to be fixed ahead.

  2. Alex says:

    April 6, 2017

    Have any plan for support QML syntax?

    • Anastasia Kazakova says:

      April 6, 2017

      Not yet (though https://youtrack.jetbrains.com/issue/CPP-4576), but do you think it makes sense before we have qmake support?

      • Alex says:

        April 6, 2017

        I really do not know.
        But to edit the code written on QT and without qmake it is possible.
        At the moment the project written on QML write it is completely impossible.
        At us in the company all projects are going from QT to QML, and for it to write becomes absolutely impossible.

        • Anastasia Kazakova says:

          April 6, 2017

          But do you use CMake for such projects?

          • Alex says:

            April 6, 2017

            Yes, we use cmake.

            • Anastasia Kazakova says:

              April 6, 2017

              I see, thanks.
              Well. We’ll consider the QML definitely, but for the future. At this very moment there are tasks with higher priority and the resources are limited.

      • Kitsune Ral says:

        April 23, 2017

        Surely it does. The project I’m working on is CMake-based with half of user interface made in QML. It works quite well in Qt Creator; but CLion’s code model (for C++) is more consistent and your refactoring (for C++) works better than Qt Creator’s. So I’m working in one of two IDEs, depending on what kind of work I’m doing right now.

  3. Jan Svoboda says:

    April 6, 2017

    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:

      April 6, 2017

      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:

    April 6, 2017

    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:

      April 7, 2017

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

    • Anastasia Kazakova says:

      April 7, 2017

      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:

        April 12, 2017

        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! https://youtrack.jetbrains.com/issue/CPP-6352

        Keep up the great work!

        • Anastasia Kazakova says:

          April 12, 2017

          Thanks for your support!

        • Olof says:

          April 13, 2017

          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: https://insights.ubuntu.com/2016/04/14/howto-ubuntu-on-windows-2/

          Here’s a version of XMing: https://sourceforge.net/projects/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
          $ clion.sh &
          $ 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:

            April 13, 2017

            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:

          April 13, 2017

          Oh, also, it said this:

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

          in the event log.

    • Sky Schulz says:

      November 30, 2017

      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.

      • Anastasia Kazakova says:

        December 1, 2017

        So am I right you develop on Windows mostly? And what is your embedded target? Do you use msbuild for it?

  5. Olof says:

    April 6, 2017

    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:

      April 7, 2017

      Thanks for your support, Olof!

    • Roman says:

      April 7, 2017

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

      • Anastasia Kazakova says:

        April 9, 2017

        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:

          April 13, 2017

          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.

          • Anastasia Kazakova says:

            April 13, 2017

            Thank you for your support!

  6. Tano says:

    April 7, 2017

    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:

      April 7, 2017

      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:

    April 7, 2017

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

  8. Nestal Wan says:

    April 7, 2017

    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:

      April 7, 2017

      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:

        April 7, 2017

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

        • Anastasia Kazakova says:

          April 7, 2017

          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: https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems. We’ll investigate if we could reduce the memory usage somehow.

          • Nestal Wan says:

            April 7, 2017

            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.

            Thanks.

            • Anastasia Kazakova says:

              April 7, 2017

              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:

    April 19, 2017

    I’ll bang the drum for this feature: https://youtrack.jetbrains.com/issue/CPP-7589

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

  10. Jean-Marc says:

    April 25, 2017

    Hi,

    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.

    Yours,

    • Anastasia Kazakova says:

      April 26, 2017

      Thanks, I’ll check and let you know asap

    • Anastasia Kazakova says:

      April 26, 2017

      We’ve resent the email.

  11. Marco says:

    July 16, 2017

    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:

      July 17, 2017

      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.

Subscribe

Subscribe for updates