CLion 1.2 roadmap

Hi,

Since CLion 1.1 came out, we’ve spent 2 weeks sorting out your feedback and looking into our plans. Then we got together and discussed the roadmap for CLion 1.2, and today we are ready to share it with you.

In brief, we are planning the next release to be out before winter with many improvements in various areas: debug, performance, parser, CMake support. And we hope to have Google Test on board in CLion 1.2. See the detailed plan below.

Please note it’s a preliminary plan, so we can’t guarantee that all of the features listed below will be ready for CLion 1.2, as well as other features may be included unexpectedly.

  • Google Test support.
  • Continue the work on project scopes, started in CLion 1.1.
  • Further C++ parser fixes and improvements.
  • CMake intellisense, especially variables and custom commands completion.
  • Debug: attach to process feature and performance improvements.
  • Overall performance improvements.

Stay tuned not to miss the EAP launch!

Develop with pleasure,
The CLion Team

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

30 Responses to CLion 1.2 roadmap

  1. Jakub says:

    Great news about Google Test. Are you planning to write your own test runner or use CTest (‘d be great) for it?

    • Anastasia Kazakova says:

      We actually have own Google Test implementation in AppCode. But now we are still considering all the options.

  2. Dmitry says:

    Please add to roadmap at least CPP-3567 and CPP-905.

    C/C++ IDE without memory inspector can’t be 1.2 and can’t have a price $99 (yes, I already bougth it this spring).

    • Anastasia Kazakova says:

      Currently you can inspect memory addresses in LLDB/GDB debugger console, when debug process is running. Some extra UI will be considered a bit later.

      Thanks for pointing to CTest. We already have some working implementation of Google test runner with UI views and actions like rerun failed tests, etc in AppCode. While integrating Google Tests into CLion, we’ll for sure consider all the options and select which test runner to use.

  3. Robin says:

    Should really add a custom build command feature soon

    • Anastasia Kazakova says:

      Could you please explain the usecase? How do you want to use it, with which options and when?

      • Robin says:

        Well people are asking for support for misc. build systems – just adding a functionality to allow users to supply a build/clean command would at least allow one to use any build system easily.

        Personally I use CMake, but use ninja & the vs compiler for building and visual studio for debugging – I just have a bat file that sets up my environment vars, runs ninja and does some other misc tasks after (moving build results etc)
        I just currently execute it via the console in clion

        • Anastasia Kazakova says:

          Actually there is no option to support just pure build command, otherwise it would be wrong code resolve in the editor and intellisence won’t work correct. CLion need to parse the build-system files, not just run a build command. That’s why it takes take to add new build system, however we have this in plans for sure, still not for 1.2

          • Robin says:

            >”Actually there is no option to support just pure build command”
            That’s why I’m saying you should give us the option to specify a command to run when hitting the build button 😉
            >”otherwise it would be wrong code resolve in the editor and intellisence won’t work correct”
            Yes I realize, but for example I am using CMake for my project regardless – I can see other people just adding a pseudo CMake file to get intellisense working aswell – It’s not that hard (for small-medium sized projects anyways).
            Of course it won’t be as good as a proper CMake solution with all dependencies and such in CMake aswell, but it’ll be a start

          • Anastasia Kazakova says:

            But what’s the point, taken into consideration that in that case editor won’t provide correctly working intellisense for you?

  4. PanteR says:

    Where remote debugging???

  5. Ryan Ware says:

    Still nothing for GNU make. Disappointing. Maybe that’s one reason to do the aforementioned custom build command?

    • Anastasia Kazakova says:

      Actually this is not only about build command. Another project model support in CLion means take and use for parsing all the information provided by the build system (file includes, header search paths, vars, flags, etc.).
      Currently it’s done for CMake only. Makefiles are the most probable candidate for project model #2 in CLion, but not in 1.2. We’d like to finish all the work around CMake first to be able to polish the general project model interface to use it for other systems like Makefiles, qmake, etc.

      • Ryan Ware says:

        I agree true Makefile support is more than just a build command. I look forward to a full project model supporting Makefiles in the future.

  6. Jonathan Reyna says:

    I’ve been using 1.1 for about a week now, and really like it. I see TONS of potential!!

    I’m excited to see what JetBrains will do in the coming releases. This next iteration sounds great!

    I would like to mention though that I wanted to use LLDB and Clang with CLion on Linux, and found that I could change it from using GDB and GCC. It would be nice to have that option.

    It would also be nice to have the option to use the AST from libclang when parsing code for completions, errors, warnings, etc.

    Thanks for doing a great job (as usual)!

    • Anastasia Kazakova says:

      Thanks!

      You can use clang on Linux right now, just point it in CMake correctly.

      For LLDB on Linux, please, upvote this – https://youtrack.jetbrains.com/issue/CPP-3588.
      We are not using clang AST for parsing, since we have our ow parser, but we are planning to integrate clang annotator for built-in warning, error and other problems displayed in the editor on-the-fly – https://youtrack.jetbrains.com/issue/CPP-81.

      • KB says:

        CLion’s parser leaves a lot to be desired. C++ generally cannot be parsed until it is compiled. While I realize that your company has a lot of parser experience, writing parsers is fun, and learning to use somebody else’s code is not fun, applying “not invented here” in this case will not result in a reasonable product for C++. The sooner libclang is used for all parsing in CLion, the better off both your company and your users will be.

  7. wl.nicholas says:

    The debugger performance problem should be carefully inspected. With a non-trivial project, the debugger is nearly unusable. I have to turn to QtCreator for help.

    Question: does “Debug: attach to process feature” include opening an external binary (compared to attach to a running process) which is generated by other build system?

  8. Hi,
    I voted for Makefile support, so, of course, disappointed it’ s not in. Eclipse allows you to select a Makefile and create a target (EG all, clean) and then to be able to run make for the targets you have created. It’s very simple, and all I would need to be able to use CLion.
    Regards,
    Martin.

    parse a Makefile

    • Anastasia Kazakova says:

      Thanks for the feedback. How CLion works with CMake – it does not simply prepare a command to build your project, it takes all the info from CMake files (header search paths, flags, vars, etc.) and uses it in code parsing/resolving. That means it does the complete analysis of your CMake files and parse the code correctly, based on this info. So another build system means another project model supported in this way. We’ll come to it, however a bit later.

  9. Sebastian Geiger says:

    Please support plain C more like a first class citizen. When importing a non CMake project into CLion it always assumes a C++ project even if its a plain C project. An option dialog or automatic recognition of the language would be nice.

    Sometimes I get warnings or errors in my C code eventhough it compiles fine. Especially with GNOME’s Gtk+ and glibs GObject system which makes extensive use of macros.

    Sometimes functions are being marked as unused eventhough they are just being used from the depth of a macro. Also navigation between macros that are called by other macros does not work properly.

  10. mark says:

    +1 for C, make, doxygen, and remote debugging support. Not everybody works with C++ on Android and we need good IDEs, too.

Leave a Reply

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