AppCode
CLion
DataGrip
GoLand
IntelliJ IDEA
MPS
PhpStorm
PyCharm
Rider
RubyMine
WebStorm
Toolbox App
.NET Tools
ReSharper C++
Space
TeamCity
Upsource
YouTrack
HubCLion 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:
- Ability to create additional CMake configurations and other related changes
- Project templates
- GCC6 support
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):
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:
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:
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:
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.
After you click Create, CLion will generate the sample project for you and pre-fill root CMakeLists.txt with the necessary information:
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.
Your CLion Team
JetBrains
The Drive to Develop
Marc-André Renaud says:
December 14, 2016Would 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, 2016We’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, 2016I 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.
Anton Makeev says:
December 19, 2016Currently it’s not possible to give configurations and build types different names, but you still can have several configurations with same (e.g. debug) build type.
Though there are some known usability issues with this case https://youtrack.jetbrains.com/issue/CPP-8369, https://youtrack.jetbrains.com/issue/CPP-8335, https://youtrack.jetbrains.com/issue/CPP-8334.
We’ll consider possible improvements in scope of https://youtrack.jetbrains.com/issue/CPP-2714 and https://youtrack.jetbrains.com/issue/CPP-7578
Tom Alexander says:
January 3, 2017Yes, this would be helpful for me as well. I currrently maintain two workspaces, one for arm cross compilation and another which uses google unit test projects. Being able to create a cmake configuration that points to a different cmake file would allow me to wrap everything into one workspace.
Henry says:
December 14, 2016Whoa! 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, 2016Not 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.
Anastasia Kazakova says:
December 22, 2016yes, we do consider this: https://youtrack.jetbrains.com/issue/CPP-547
Jakub says:
December 14, 2016I 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, 2016Thank 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, 2016Generally 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, 2016Thank 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, 2016Yes, already voted 😉
Anders says:
December 15, 2016I 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, 2016Good 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, 2016Yes, 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, 2016I see, thanks for the details.
Jan Möller says:
December 16, 2016I 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, 2016Thanks for the feedback. We’ll consider the case.
Anton Makeev says:
December 19, 2016Jan, here is a corresponding request: https://youtrack.jetbrains.com/issue/CPP-8417. Please feel free to leave your ideas in the comments.
Christian Auby says:
December 21, 2016The 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.
Anastasia Kazakova says:
December 21, 2016Thanks. We are considering it under: https://youtrack.jetbrains.com/issue/CPP-7919
Sanjay Arvind says:
November 6, 2017Is it possible to create our own project template for main.cpp?
Anastasia Kazakova says:
November 6, 2017Not yet unfortunately: https://youtrack.jetbrains.com/issue/CPP-5089