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
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.
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?
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.
Currently 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
Yes, 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.
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?
Not yet, but you can share your expectations in the tracker and we’ll consider.
@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.
yes, we do consider this: https://youtrack.jetbrains.com/issue/CPP-547
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.
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?
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.
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
Yes, already voted 😉
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.
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
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.
I see, thanks for the details.
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.
Thanks for the feedback. We’ll consider the case.
Jan, here is a corresponding request: https://youtrack.jetbrains.com/issue/CPP-8417. Please feel free to leave your ideas in the comments.
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.
Thanks. We are considering it under: https://youtrack.jetbrains.com/issue/CPP-7919
Is it possible to create our own project template for main.cpp?
Not yet unfortunately: https://youtrack.jetbrains.com/issue/CPP-5089