CLion 2016.3.2 EAP: CMake configurations, project templates and GCC6

Posted on by Anastasia Kazakova

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

Comments below can no longer be edited.

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

  1. Marc-André Renaud says:

    December 14, 2016

    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.

    • Anton Makeev says:

      December 15, 2016

      We’ll probably add something like that in future, in scope of https://youtrack.jetbrains.com/issue/CPP-1537. (Can’t give any ETA).

      Though I don’t see how it could help unit testing directly, since they usually tightly depend on the main targets. If you want to split production and testing CMakeLists, consider using a separate CMakeLists for your tests and add it using add_subdirectory command.

      Will it work for you?

      • Marc-André Renaud says:

        December 15, 2016

        I made some test and your solution will work.

        Would it be possible to set the configuration name apart from the build type? This way it would be possible to have a configuration in debug with options and generation path for a build using cross-platform compiler while an other configuration also in debug with another name could have option for windows or linux compiler.

        This way it would be possible to have a target aimed for a microcontroller and run windows unit test in the same project.

  2. Henry says:

    December 14, 2016

    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?

    • Anastasia Kazakova says:

      December 14, 2016

      Not yet, but you can share your expectations in the tracker and we’ll consider.

      • Sebastian says:

        December 21, 2016

        @Anastasia,
        it would be really awesome if the following parts were configurable in custom templates:

        * Create a default CMakeLists.txt for the custom template that already includes certain C or C++ libraries preconfigured and ready to use.
        * Create a default main.c or main.cpp file that already contains code specific for the respective template.

  3. Jakub says:

    December 14, 2016

    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:

      December 14, 2016

      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:

        December 20, 2016

        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.

        • Anastasia Kazakova says:

          December 21, 2016

          Thank you for such a detailed reply. We are currently collecting the feedback to understand what can be done to serve most cases. We’ll consider your case, thank you again.

          And looks like it’s aligned with this: https://youtrack.jetbrains.com/issue/CPP-8417

          • Jakub says:

            December 21, 2016

            Yes, already voted 😉

  4. Anders says:

    December 15, 2016

    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:

      December 15, 2016

      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:

        December 15, 2016

        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.

        • Anastasia Kazakova says:

          December 15, 2016

          I see, thanks for the details.

  5. Jan Möller says:

    December 16, 2016

    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.

    • Anastasia Kazakova says:

      December 16, 2016

      Thanks for the feedback. We’ll consider the case.

    • Anton Makeev says:

      December 19, 2016

      Jan, here is a corresponding request: https://youtrack.jetbrains.com/issue/CPP-8417. Please feel free to leave your ideas in the comments.

  6. Christian Auby says:

    December 21, 2016

    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:

    November 6, 2017

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

Subscribe

Subscribe for updates