Our school learnt us how to use and create our own Makefile, but I want to learn how to use CMake, so I can use CLion at it's max potential. My main difficulty is finding how to include a external library with CMake, I had a project based on the Ncurses library for C,. But had to do the whole project with a Makefile, since I don't. There are at least three different ways to run: Right click on a makefile and select Run Have the makefile open in the editor, put the cursor over one target (anywhere on the line), hit alt + enter, then select make target Hit ctrl / cmd + shift + F10 on a target (although this one didn't work for me on a mac). On the main menu, choose File New CMake The thing is CLion now supports CMake, Gradle, Compilation Database and Cargo projects (the last ones via the Rust plugin). When a project uses some other build system (like custom build system in your case), the 'CMake project is not loaded' warning is shown.
NewsReleases- Note that from version 2020.2 CLion has support for Makefile Projects. While Makefile projects simplify the initial import of the project into CLion some major deficiencies exist, including the inability to include header files and unit test files in the project index.
- CLion 2020.2: Makefile Projects, C20, Enhanced Code analysis, Doctest, and Other Unit Testing Support Improvements.
Good news everyone – we’ve released CLion 2020.2!
With this version we make CLion available for a greater variety of C and C++ projects by adding long-awaited Makefile projects support. We’ve continued adding support for the new C++20 standard, which is expected to be officially published this year. We’ve also addressed many typical C++ code issues with new and improved code analysis checks, and we’ve significantly enhanced unit testing framework integration and code coverage workflow.
To update to this version, you can use the Toolbox App, a snap package (on Ubuntu), download the installer from our website, or apply the patch update to upgrade from the last 2020.1 build.
Here is a quick overview of the main highlights. If you are interested in the specific details, please read on:
Makefile projects support
Our developer ecosystem study revealed that the top 3 project models for C++ projects are CMake, Visual Studio, and Makefiles. From the very first versions, CLion has treated CMake as a first-class citizen, providing many productivity-boosting features for it. Among other supported project models, in CLion you’ll find Gradle, Compilation Database, and Bazel (via a 3rd-party plugin). This list of supported project models is probably the biggest limitation of CLion. CLion 2020.2 is now open to a wider variety of C and C++ projects due to the introduction of a much-requested feature – support for Makefiles projects!
To be able to load a Makefile project, CLion runs
make
on it, by default with the --just-print
option to avoid actually building it, and parses the output of the make
command. If parsing is successful, CLion loads the project and enables all the smart IDE features for it.The arguments of the
make
command, as well as the Build target and Clean target commands used by CLion to load the project, are configurable in Settings/Preferences | Build, Execution, Deployment | Makefile:In Run/Debug configurations you can select the Makefile Application configuration, allowing you to run and debug your Makefile targets.
Support for makefile projects in CLion is still in its early stages with various limitations and known issues. However, we’ve tested it on a long list of projects, which you can find on our Confluence page. We also want to sincerely thank all early previewers who gave this new feature a try and shared their feedback! Feel free to check out this blog post for the implementation details, a few configuration tips, and a list of known issues, as well as our future plans in this direction. We also encourage you to watch this short demo from Phil Nash to see Makefile projects support in action:
Modern CMake support
CLion 2020.2 bundles CMake 3.17 and now offers necessary support for a few useful features from the recent CMake updates:
- CMake precompiled headers.
Ninja Multi-Config is an option (
-G 'Ninja Multi-Config'
) for the Ninja generator in CMake that allows you to get build files generated for all configurations at once. While CLion 2020.2 generates them all, it still uses only one, selected in the CMake Profile settings. We are planning to add a UI to support multi-config generators, later (CPP-20890).The precompiled headers (PCH) technique can speed up compilation by creating a partially processed version of some header files, and then reusing it during subsequent compilation runs. CMake precompiled headers is a great unification feature, which allows you to organize precompiled headers in your project in a compiler-independent way. You just use the
target_precompile_headers
command to add header files to the PRECOMPILE_HEADERS
and/or INTERFACE_PRECOMPILE_HEADERS
properties of a target. You no longer need to remember the multitude of compiler flags for PCH and pass them via the project model! New CMake commands and properties are now supported by CLion, which means code resolve and all IDE features work correctly:Note that this doesn’t currently work for Cygwin/WSL/Remote toolchains, but we plan to add it later.
Imagine the situation when you open a CMake project that has a CMake folder already generated. CLion can open the project without regenerating the folder, which saves a considerable amount of time for some projects. This feature previously worked only for the Makefile generator, but now it is supported for all generators (like Ninja, or others). Give it a try!
You’ll also find an updated UI in Settings/Preferences | Build, Execution, Deployment | CMake, and a new list of CMake actions in Find Action, which you can now assign a shortcut to for your convenience: CMake Settings, Stop CMake project reload, and Open CMakeCache file.
Phil Nash produced a short video on CMake enhancements in CLion 2020.2:
Better C++20 standard compliance
This year brings a new C++ standard to developers. In this release, we devoted a lot of effort into improving the C++ language support in CLion. The Clangd-based language engine is generally more stable now with the C++20 code. In addition, a few more specific features have been added:
- Code completion for C++20 keywords:
char8_t
,consteval
andconstinit
,co_await
,co_return
, andco_yield
. - For designated initializers, code completion now works for fields from a base class:
- Not only is the C++20
explicit(bool)
now highlighted correctly, name hints for condition arguments also work there, as do navigation and refactorings: - In range-based
for
loops with theinit
statement, refactorings like Rename work for variables in the loop in CLion 2020.2.
Code analysis
In this release we improved the built-in code analysis in CLion by completely reworking some of the checks and adding a few new ones:
- We added a new inspection for C++20 Concepts. It suggests constraining local variables declared as auto if the result of a constrained function call is assigned to them:
Note the limitation: this inspection is not supported for function templates with arequires
clause constraining the return type. - A check has been added to catch dangling pointers. We all know how dangerous cases with double-free and use-after-free can be. With a few limitations, CLion 2020.2 now helps you to detect such cases:
- The Simplify code inspection has not only become more accurate, but it’s also now less CPU-consuming. Fine-grained configuration options are now available under Settings/Preferences | Editor | Inspections | C/C++ | General | Simplifiable statement:
- TheLoop condition is never updated inspection, similarly to Clang-Tidy’s clang-tidy:bugprone-infinite-loop, detects situations where a loop condition is not updated inside the loop. CLion’s inspection works nicely for loops with exit points and can handle cases with lambdas or references.
- The Unused code inspection and Data Flow Analysis in general were both greatly improved in this release.
CLion 2020.2 also introduces a new Inspection Widget and the Problems tool window to check the list of warnings and errors in the current file:
Here’s a video from Phil Nash on the C++20 and code analysis improvements:
Unit testing
What’s your favorite unit testing framework? Do you write unit testing as all? The developer ecosystem study that we carried out in the beginning of 2020 found that 34% of C++ developers don’t write unit tests, while 15% do but don’t use any specific framework. However, among the majority who do run unit tests on their C++ projects, the 5 most popular frameworks were identified as Google Test, Catch, Boost.Test, CppUnit, and Doctest.
CLion has already supported the top 3 frameworks for a long time. Version 2020.2 enhances integration with the newer versions of Google Test and Catch2 by adding support for:
- The
GTEST_SKIP()
macro in Google Test, to skip tests at runtime - Catch2 template tests.
This version also adds Doctest to the list of the frameworks supported in CLion:
This mean that Doctest tests are detected by CLion and Run/Debug configurations are created automatically when you run an individual test or all tests in a file, and the results of the test launches are presented in the built-in test runner, which helps analyze the test results, navigate to the source code, and rerun failed tests or all tests. Learn more about Doctest support in CLion in this dedicated blog post.
Code coverage is important – when you do unit testing for your code, it’s useful to see how well your code is covered by the tests. You can run your tests with coverage in CLion, and starting from 2020.2 you no longer need to manually create a CMake Profile and specify all the necessary compiler flags in it. If the proper configuration is missing, CLion will now create one based on the CMake profile you are currently using.
Phil Nash produced a short video on unit testing enhancements in CLion 2020.2:
Updates to the Go to Declaration or Usages action and Clangd configuration
You probably know that CLion handles C and C++ code with the help of two language engines: one is built into CLion, and the other is based on Clangd. The Clangd-based engine is younger but is evolving faster than CLion’s own engine, and incorporates a huge amount of work done by the C++ community to support new language features. Our team implements code highlighting, completion, parameter hints, unique code analysis features (like Data Flow Analysis, and others), some navigation actions, and other features on top of it. You can check out our online documentation for a detailed comparison of the two engines. CLion 20202.2 shows the LLVM Clang revision used for the Clangd-based language engine so that you know what to expect in terms of C++ support and built-in Clang-Tidy checks:
We’ve also applied some effort to making sure the Clangd-based engine is as stable as possible. We are now so confident in it that it has become the default language engine in CLion and the option to turn it off has been removed.
Another important change is the behavior of the Go to Declaration or Usages action (Ctrl+Click / Ctrl+B on Linux/Windows, ⌘Click / ⌘B / force-touch on macOS). A new setting under Settings/Preferences | Editor | General | Go to Declaration or Usages allows you to specify whether it should show the list of usages or show the associated declaration when the action is invoked on a definition. If you’d like to learn more about it, check out this blog post.
Debugger improvements
CLion integrates with the GDB and LLDB debuggers, and on Windows it also comes with the JetBrains LLDB-based debugger for the Microsoft Visual Studio toolchain. This debugger is now used in two of our IDEs – CLion and Rider for Unreal Engine. In version 2020.2 it gets lots of improvements: we’ve eliminated freezes on stop and a number of crashes, made general performance improvements, and introduced automatic thread naming, in addition to some other fixes. The debugger is bundled with CLion and is enabled automatically when you select the Microsoft Visual Studio toolchain. Give it a try and let us know what you think!
CLion 2020.2 updates the bundled GDB STL pretty printers and upgrades the bundled version of GDB to 9.2.
IDE performance
We still treat IDE performance as our top priority, and we continue to fix UI freezes and improve CPU and memory consumption. Among many such fixes in this release, one deserves a special mention: in order to avoid editor performance degradation, CLion now inserts a backslash when you press
Enter
inside a macro definition. The macro definition will quite likely be continued on a new line, so this saves the IDE from redundantly reparsing activity.Easier embedded development with the updated PlatformIO plugin
Clion Makefile Support Number
The PlatformIO plugin in CLion helps you start an embedded project faster. During this iteration we improved it by adding highlighting in
platformio.ini
files, automatically generating various useful Run/Debug configurations, and creating CMake Profiles for the CMAKE_CONFIGURATION_TYPES
entries from the PlatformIO projects. Our next step will most likely be to rework the project model approach (which currently generates CMake for CLion), however we might postpone this until 2021.Clion Makefile Support Center
VCS support update
As usual, the IntelliJ Platform has been updated with many improvements to VCS support. This includes new and richer functionality in the GitHub Pull Requests view. Learn more about this on the IntelliJ IDEA page.
Our WSL2 users will be happy to learn that Git installed on WSL2 is now automatically detected by the IDE, and all Git-related features automatically switch over to work with it.
That’s it for this release, please give CLion 2020.2 a try. Update today if you have an active subscription, or start your free 30-day trial to evaluate the new features!
Your CLion team
JetBrains
The Drive to Develop
JetBrains
The Drive to Develop
This article describes a workaround which you can use to work with Meson or other build system in CLion using compilation databases and File Watchers.
Our example shows how to construct a meta build system which monitors changes in the Meson build script, and then regenerates and reloads the compilation database accordingly. This way, it lets you manage a Meson project to a full extent from within CLion. Moreover, you can build and run/debug such projects with the help of custom build targets and custom Run/Debug configurations.
Step 1. Create a Meson build directory and get the compilation database
Suppose we have a simple Meson project consisting of a main.c file and the corresponding meson.build script, both located in the meson_test directory.
# meson.build project('tutorial', 'c') executable('demo', 'main.c')
- Create a build directory for the project:
- Meson automatically generates compile_command.json in builddir.If you need to create it manually, run the following ninja command:cd builddir ninja -t compdb c_COMPILER cpp_COMPILER > compile_commands.json
Step 2. Open and configure the compilation database in CLion
- In CLion, go to File | Open and select the compile_command.json file created in step 1. Select Open as Project when prompted.
- By default, CLion sets the directory containing compile_command.json as project root. Go to Tools | Compilation Database | Change Project Root and change it to the top-level meson_test directory.
Step 3. Install the File Watchers plugin
- Go to Settings / Preferences | Plugins, switch to Marketplace, search for File Watchers, and install the plugin:
Step 4. Register meson.build as a recognizable file type
- Go to Settings / Preferences | Editor | File Types.
- In the Recognized File Types section, click and specify the file type name (for example, Meson ).
- Select Meson in Recognized File Types, then click in the File name patterns field. Set the file pattern (meson.build in our case):
Step 5. Create a File Watcher for meson.build
Now we can create a File Watcher to follow up the changes in meson.build.
- Go to Settings / Preferences | Tools | File Watchers and add () a new custom watcher.
- Configure the following settings:
- In the File to Watch section, assign the watcher to Meson (the file type we created in step 4 ).
- Set the Scope to Project files.
- The Tool to Run on Changes section controls the program to be when the watcher is triggered. In our case, its
ninja
with thereconfigure
argument, which will re-generate the compilation database.Also, we need to change the Working directory the builddir.
Step 6. Modify meson.build
- As an example of how we can change the build script, let's add a new file (New | C/C++ Source File in the context menu of the Project view) and call it calc.c. Then we can add this file in meson.build:
- Right after that change in meson.build, the file watcher is triggered to run
ninja reconfigure
. This command will regenerate the compilation database, and CLion will automatically reload it so the project gets synchronized with the modified build script. - We can check that now there are two entries in compile_commands.json:
Step 7. Make the File Watcher global
- The final thing that we might want to do is make the Meson_watcher global. With this setting enabled, the watcher becomes available across all projects so you will be able to easily reuse it for other Meson applications in CLion:
This way, the combination of a File Watcher and a compilation database creates a mechanism to work with Meson projects without leaving CLion to edit the build scripts or recreate the compilation database manually. You can apply this approach to any build system that has complementary tools for generating compilation databases.
Note that currently, in this scheme, CLion reloads the entire compilation database for each change in the meson.build that triggers the File Watcher. Due to that, you may experience performance problems when applying this workflow to large code bases.
As the next steps, you can build and run/debug Meson projects with the help of custom build targets and custom Run/Debug configurations.
If you are interested in full Meson support in CLion, follow this feature request.