CLion 2016.3.2 EAP: CMake configurations, project templates and GCC6

Hi everyone,

CLion 2016.3.1 update was just announced, but we keep moving forward and today we roll out CLion 2016.3.2 EAP build (163.10154.14).

The highlights include:


Download CLion 2016.3.2 EAP

CMake workflow update

Configurations

CLion’s approach to CMake has changed in v2016.3. CLion stopped building all 4 CMake configurations by default, letting you select which ones you need. While this reduces memory usage, as well as the time required for CMake reload, there was some inconvenience that our users reported in blog post comments, the tracker and other social channels.

After considering all the use cases carefully, we’ve come up with a UI that allows you to create additional CMake configurations (as many as you need):
cmake_additional_config

Go to Settings/Preferences | Build, Execution, Deployment | CMake and create any number of CMake configurations from scratch, or copy existing ones (with all the settings pre-filled). When done, additional resolve context will be available in the bottom right-hand switcher in the editor:
resolve_context

By the way, in case you have custom configurations created by the setting CMAKE_CONFIGURATION_TYPES, they will appear in the settings’ drop-down as well.

In the Run/Debug configuration settings dialog, you can switch between available CMake configurations:
clion_run_debug_configuration

If you used to switch between Release/Debug (or other configurations) during development, now you can create all the necessary CMake configurations and corresponding Run/Debug configurations (as necessary), and switch between them with ease.

Please, note, projects with multiple CMake configurations added in 2016.3.2 EAP might not work properly in v2016.3, but work ok in 2016.3.1 bug-fix update.

Exclude generated folders

CLion 2016.3 allows changing the CMake generation folder path. Among other benefits, it brings the ability to generate in-source. However, this folder was not excluded from the project in CLion, which would cause usability issues. Now in the CLion 2016.3.2 EAP build, the directories are excluded, which means that:

  • Find in path and other searches do not go through the files in these folders; and
  • These folders are excluded from VCS.

CMake output console

CMake output console has been updated to support error highlighting, links to corresponding CMake files, and navigation to next/prev errors:
cmake_console_errors

Besides, CMake 3.6.3 was bundled into this EAP build.

Project templates

If you plan to start a project from scratch, we’ve got good news for you! Project templates finally have made their way to CLion. There are several options available in the dialog:

  • Select either a C++ project or a pure C project.
  • Select executable or library.
  • Select language standard and library type.

project_templates
After you click Create, CLion will generate the sample project for you and pre-fill root CMakeLists.txt with the necessary information:
cmake_lib_cpp

Project templates for Swift will also join a bit later (CPP-6155), as will compiler and additional libraries settings in the dialog (CPP-7919). Feel free to share your ideas in the corresponding tickets.

GCC6 support

This build fixes the problem with correct recognition of <cstdlib> (in case of GCC6) (CPP-7573). This work also covers most of the issues with #include_next (CPP-3821), and thus we are glad to announce that GCC6 can now be successfully used in CLion. If you still experience any issues, please, let us know.

Full release notes are available here.


Download CLion 2016.3.2 EAP

Your CLion Team

JetBrains
The Drive to Develop

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

25 Responses to CLion 2016.3.2 EAP: CMake configurations, project templates and GCC6

  1. Marc-André Renaud says:

    Would it be possible to specify a different CMakeLists file and its path for each configuration? This way it would be possible to create configurations for unit testing frameworks without overburden the project main CMakeLists.

  2. Henry says:

    Whoa! Project templates is something I didn’t know how much I needed until now. This is awesome!

    Is it possible to create our own project templates?

  3. Jakub says:

    I like that you have introduced better handling of configurations. It’s great and thank you for that.
    But… (yeah, there must be something 😉 )
    The way it’s not, it ties target to configuration. I already have a couple dozen targets. Now, if I frequently switch between configurations (which I do), I have to double the number of targets AND remember to switch between them so that I do not end up changing debug stuff while running release.
    I’m not sure if I’m clear about my issue.

    • Anastasia Kazakova says:

      Thank you for the feedback. Could you please also explain the use case – why and in what situations do you switch, how do you use debug/release configurations?
      Am I right that before 2016.3 you actually have the same problem? Or do I misunderstand the case?

      • Jakub says:

        Generally I sometimes have an error in Release only. I have to reproduce it by writing some tests but I really want to be able to debug those so I end up switching back and forth between debug an release. There is a Trace configuration that is almost like Release but leaves some assertions and has extensive logging build in. Again sometimes it changes the timings so I’m switching between those, changing the code for one or the other and it’s importatnt the the code I’m changing is exactly the one I’m going to run.

        Also in all the IDEs I’ve ever used I could simply choose a target and it would be run using the current configuration. In CLion I need 3 “targets” – same executable, same parameters and the only difference would be the configuration. This is not ideal.

  4. Anders says:

    I like the re-introduced build configurations!

    One suggestion, currently, it’s possible to set environment variables for each build configuration. Could you make it possible to also source a script, setting a large number of variables? This would make it a lot easier to have a mixture of host and target build configurations. (I’m building for either my laptop or for our embedded Linux ARM-target).

    I’m activating the cross-compiler by sourcing a setup-script, that amongst other things sets up the variable mentioned at http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#sdk-running-the-sdk-environment-setup-script. There’s also a CMake toolchain files that gets added.

    • Anastasia Kazakova says:

      Good suggestion. Thanks! https://youtrack.jetbrains.com/issue/CPP-8414

      CMake toolchain file can be set via CMAKE_TOOLCHAIN_FILE var. Isn’t it? Still there is a request about convenient switch between them: https://youtrack.jetbrains.com/issue/CPP-7578

      • Anders says:

        Yes, the CMAKE_TOOLCHAIN_FILE can be used for the toolchain itself. (Deep down, the OE-generated SDK aliases cmake to ‘cmake -DCMAKE_TOOLCHAIN_FILE=…’, but this can easily be solved in the build configuration dialog. At least if it’s possible to use env variables in the “CMake options:” field. I’d like to be able to set “-DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake”).

        However, there might be more tools needed, thus the PATH exported in the environment setup file is needed. Also, the environment setup file sets up CC, CXX etc to point to the cross-compiler, eg arm-oe-linux-gnueabi-g++, so the PATH is needed in order to find the binary.

  5. Jan Möller says:

    I like the (re-introduced) build configurations, but personally I think targets and build configurations should be separated. They are separate concepts and, at best, I would like to have a drop down menu for target in the top right corner of CLion and another drop down for build configuration right next to it. I switch between build configurations very frequently, and currently I either have to duplicate all my build targets (one for Debug, one for Release for example), or I have to go through the Edit Configurations window every time I want to switch.

  6. Christian Auby says:

    The new project wizard already saves you some time, but it would be even better if there were fields to enter additional compiler and linker flags.

  7. Sanjay Arvind says:

    Is it possible to create our own project template for main.cpp?

Leave a Reply

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