CLion 2016.3 EAP: CMake changes and overload resolution
Release time is quickly approaching, but we still have lots of goodies to show you. At this stage your feedback is very important and highly appreciated. Share with us in the comments below and/or our tracker. Having said that, we are glad to announce that new CLion 2016.3 EAP, build 163.6957.27, is available now. A patch update will be rolled out shortly for those using the previous EAP (build 163.6512.7).
The most valuable improvements include:
CMake workflow changes
There were lots of discussions around our approach to CMake and how CLion deals with the CMake generation. After considering all the use cases carefully, we’ve decided to reorganize it and incorporate our users’ suggestions. This new approach seems to be more flexible and fits more workflows. The main changes are as follows:
Select generation directory
Previously, users were only allowed to change the directory where the final build artifacts are stored, while the CMake generation directory was set internally by CLion. Now users can provide the path to the preferred generation directory in CMake settings:
By default, if nothing is set, the cmake-build-debug folder will be created in the source tree.
Open project from an existing CMake-generated folder
These changes made it possible to save time on opening projects, for which CMake generation was called already. In addition, it makes possible workflows with switching between building in the shell and building in CLion. You just need to point CLion to the folder that contains CMakeCache.txt, or open CMakeCache.txt file as a project:
A few things worth noticing here:
- CLion will suggest opening the corresponding source directory and mark the directory with CMakeCache.txt file as a build directory.
- If you already opened the corresponding source directory in CLion, project settings (generation folder and selected build configuration) will be updated.
- At this stage CLion is not able to work with non-Makefiles generator output, so in this case the files will be generated from scratch (for example, if you were using Ninja generator).
Also please note that for now CLion cannot find an existing generation folder on its own.
One configuration at a time
With this EAP, CLion allows only one configuration at a time. So you can select from Debug, Release, RelWithDebInfo, MinSizeRel or any custom configuration in the CMake settings. That makes it impossible to quickly switch between these configurations in the editor to resolve the code in the selected context. However, this approach is aligned with the most popular use case when work is done in Debug mode and Release is used to make final builds. Also, having fewer configurations saves time and memory, which can be quite noticeable for big projects.
We want to note here that we are still considering a solution that would allow building as many configurations as the user needs, but it’s not going to be ready soon, and not likely before the release of 2016.3. Do share your concerns if you prefer previous approach.
CMake toolwindow and CMake Cache
Finally, CMake tool window was reworked. All tabs are now joined in one, which is easier to use. And if you want to edit CMake Cache, open the file directly in the editor or click the corresponding button in the CMake tool window:
This removes the limitation on adding CMake Cache variables. Edit the CMakeCache.txt file the way you want – and CLion will catch up on changes.
Overload resolution improvements
Overload resolution is a technique used by C++ compiler to select a candidate for a function or operator to actually call among all the overloaded options. From the IDE perspective, selection of the correct candidate affects code navigation, parameter info, code analysis, refactorings, and more. Previously a lot of false-positives in the code analysis in CLion were caused by errors in overload resolution. Today we are happy to share the results of a big overhaul in CLion in this area. CLion has become smarter and now picks the correct function and operator usages, even in code with templates:
It also made it possible to introduce two new code inspections:
- Ambiguous call:
- No matching function to call:
This work addresses a huge list of issues from the tracker and most likely a lot of problem not yet even reported to us. Thus we kindly ask you to check the update and log any new problem (with red-code or false analysis) introduced by this build.
CLion and Python
With Python support introduced, there are lots of mixed C/C++/Python projects now being developed in CLion. One of the use cases is Python C extension modules. However, debug used to fail in such case because the PYTHONPATH environment variable was being overwritten by the IDE. Besides, it caused problems in other cases when working with Python in CLion.
Today we are glad to share that this problem has been fixed!
Full release notes are available by the link.
Your CLion Team
The Drive to Develop
Subscribe to Blog updates
CLion 2024.1 EAP 4: Switch to CLion Nova in CLion Classic
The CLion 2024.1 EAP 4 build (241.13688.39) is out! It is available from our website, via the Toolbox App, or as a snap package if you’re using Ubuntu. With this build, we’re making CLion Nova available to all CLion Classic users. Switch to it from inside the IDE via the settings menu and try it …
CLion 2024.1 EAP 3: Assembly View Enhancements
Today, the CLion 2024.1 EAP 3 build (241.12662.59) is available from our website, via the Toolbox App, or as a snap package if you’re using Ubuntu. Here are the main improvements: Assembly view improvements: The Assembly view for ARM targets is now shown correctly (CPP-36901). Assembly vi…
CLion 2024.1 EAP 2: Improved Terminal and Other UX Enhancements
Some time ago, we shared our plans and directions. Just a couple of weeks ago, we kicked off our CLion 2024.1 EAP with CMake coding assistance, code analysis in device tree files, and forked processes debugging. Today, the CLion 2024.1 EAP 2 build (241.11761.23) is available from our website, via…