CMake profiles

Settings required for building a CMake project are incorporated into a CMake profile. It includes toolchain and build type, as well as CMake options such as generators and environment variables.

You can configure multiple profiles for your project in order to, for example, use different compilers or to build targets with differing settings.

Access profile settings

Do one of the following to open the CMake profile settings.

Go to Settings | Build, Execution, Deployment | CMake.
Press Ctrl+Shift+A to open the Find Action dialog and search for CMake settings:
Go to Settings | Keymap and assign a shortcut for CMake settings. Use this shortcut to quickly open the CMake settings page.

Add a new profile

Go to Settings | Build, Execution, Deployment | CMake.
Click , and CLion will add a new profile to the list.
If required, change the profile name, build type, and other settings.

Build with a profile

The enabled profiles are listed in the profile switcher.
Select the desired profile before building, running, or debugging your application.
CLion filters the list of profiles it suggests in this switcher based on whether the selected target supports that profile. For example:
Suppose you have two profiles, Debug and Release, and a target called debug_target, which is supported for Debug only:
if(${CMAKE_BUILD_TYPE} STREQUAL "Debug") add_executable(debug_target main.cpp) endif()
If you select this target in the run/debug configuration, CLion will only suggest the Debug profile.
Click or call one of the available Build actions.
Also, build is performed by default before run or debug (you can change this in the configuration settings).

Configure default profiles for new projects

Go to File | New Projects Setup | Settings for New Projects | Build, Execution, Deployment | CMake.
Configure the list of profiles to be used for all new projects by default.

You can share CMake profiles in VCS along with the project. The profiles' settings are stored in cmake.xml in the .idea directory.

Select the profile you want to share and set the Share checkbox:
Shared profiles are automatically moved to the bottom of the list.
Only the Profile settings can be shared. The Reload CMake project on editing CMakeLists.txt or other CMake configuration files option is common for all profiles and is stored in workspace.xml.
Make sure to have different names for shared and local profiles. If a shared and a local profile have the same name, the local one takes precedence and you will not see the shared one in the settings.

Disable/enable profiles

You can disable the profiles that are not currently in use to save time on loading and avoid potential errors (for example, when you have a remote profile you don't use regularly and the machine is shut down).

Use one of the following options:

Clear or set the Enable profile checkbox in Settings | Build, Execution, Deployment | CMake. Disabled profiles are grayed out in the list.
To disable a successfully loaded profile, select Disable This Profile from the configuration menu in the CMake tool window:
From this menu, you can also enable any of the disabled profiles:

CMake options

Compiler flags

In CLion, you can specify compiler flags in the CMake options field of a profile or in the CMakeLists.txt script.

Using CMake options:
Select the profile in Settings | Build, Execution, Deployment | CMake and edit the CMake options field.
Use -D with the CMAKE_CXX_FLAGS variable (or CMAKE_C_FLAGS for C projects). For example, -DCMAKE_CXX_FLAGS="-Wall -Wextra".
You can change values of existing CMake variables in the Cache variables table.
CLion also works with the --preset argument passed to CMake options. The data from the specified preset is loaded into build type, toolchain, and build directory settings.
Click to insert the project root directory macro. For more information, refer to the CMake settings reference page.
Alternatively, you can set compiler flags in CMakeLists.txt.
Add the following command with the required flags:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")

CMake toolchain files

In CMake options, you can specify a CMake toolchain file using the CMAKE_TOOLCHAIN_FILE variable.

CMake cache variables

You can view and edit the CMake cache variables in the Cache variables table:

You can add new variables either in the CMake options field or in the CMakeLists.txt file. User-defined variables are placed on the top of the table. Values of the user-defined variables are highlighted in bold, while the changed values of the other variables are shown in italics:

To remove a variable from the CMake options field, select it in the table and click or press Alt+Delete. The variable will be removed from the table or its value will be set to default after resetting the CMake cache.

To discard changes made in the current session, select a variable and click or press Ctrl+Z.

Advanced CMake variables are hidden by default, but you can show them by selecting the Show advanced checkbox:

CLion also shows the short description in tooltips for CMake cache variables:

The IDE shows Boolean values as checkboxes. Next to the checkboxes, you can see the actual values behind the Boolean variables. The following values are treated as False: 0, OFF, NO, N, IGNORE, NOTFOUND, empty strings, and values that end in the suffix -NOTFOUND. In all other cases, the value is treated as True.

When you check or uncheck the checkbox in the CLion user interface, the following pairs of values are used to configure option values: 0-1, OFF-ON, NO-YES, FALSE-TRUE, and N-Y. For any other values, the IDE converts the checkbox state to OFF-ON.

Generators

In the Generator field, you can switch between CMake generators. Use the default value for the selected toolchain or set another generator from the predefined list:


Use default	CLion uses either Ninja or Makefiles as the default generator. Ninja is used when all of the following is true: The selected toolchain is local (this excludes Remote, Docker, and WSL). The build tool configured for the selected toolchain in Ninja (bundled Ninja is the default build tool). CMake version is 3.20 or later. The project is created or opened for the first time in CLion 2021.3. The Use legacy generator for CMake 3.20 and higher checkbox in Advanced Settings is not set. In all other cases, the Makefiles generator is used.
Let CMake decide	If you choose this option, CLion will not force any generator explicitly, and CMake will decide which generator to use. By default, this is controlled by the CMAKE_GENERATOR environment variable.

Use default

CLion uses either Ninja or Makefiles as the default generator.

Ninja is used when all of the following is true:

The selected toolchain is local (this excludes Remote, Docker, and WSL).
The build tool configured for the selected toolchain in Ninja (bundled Ninja is the default build tool).
CMake version is 3.20 or later.
The project is created or opened for the first time in CLion 2021.3.
The Use legacy generator for CMake 3.20 and higher checkbox in Advanced Settings is not set.

In all other cases, the Makefiles generator is used.

Let CMake decide

If you choose this option, CLion will not force any generator explicitly, and CMake will decide which generator to use. By default, this is controlled by the CMAKE_GENERATOR environment variable.

Alternatively, you can set the generator in CMake options via -G. When the Generator field is used, CLion automatically updates CMake options and vice versa:

Current limitations

CLion uses CMake File API, which first appeared in CMake v3.14. However, CLion supports it starting from the update introduced in CMake v3.15, so if you decide to switch from the bundled CMake, make sure to use version 3.15.x or later.
For multi-config generators like Ninja Multi-Config, Xcode, or Visual Studio, CLion uses only the configuration that corresponds to the build type specified in the CMake profile (CPP-20890).

Build types

Use the Build type field to set one of the following CMake build types:

Default (corresponds to the empty value of CMAKE_BUILD_TYPE).
Debug (the default build type)
Release
RelWithDebInfo (Release with debugging information)
MinSizeRel (Release optimized for size)

To refer to the build type in CMakeLists.txt, use the CMAKE_BUILD_TYPE variable. For example:

if (CMAKE_BUILD_TYPE MATCHES Debug)
    add_definitions(-DDEBUG=1)
endif()
            

You can also create conditional statements in your code based on the current build type:

                int main(int argc, const char* argv[]) {
                #if DEBUG
                ...
                #else
                ...
                #endif
            

Custom build types

The list of the available build types is defined in the CMAKE_CONFIGURATION_TYPES command. The default value of this command is the four build types given above, but you can extend it to have other build types. For example:

                    # adding two custom build types to the cached value
                    # variable CMAKE_CONFIGURATION_TYPES should be defined before other definitions:
                    set(CMAKE_CONFIGURATION_TYPES "MyDebug;MyRelease" CACHE STRING "" FORCE)
                

After reloading the project, custom types will be available from the CMake settings:

Note that the custom types were added to the value Debug which was cached in CMakeCache.txt. So for example, if you add a new CMake profile, it will have its own CMakeCache.txt, and for this profile, the list of the available build types will contain your custom types only:

Build options

In the Build options field, you can set the options to be passed either to the build tool used by CMake or as command line parameters to CMake itself. These options will be used during the build phase.

Arguments for the underlying build tool (make, Ninja, or another one) should be preceded with --. For example, if you specify -j 5 --clean-first -- -d -p, then -j 5 --clean-first will be processed by CMake, while -d -p will be passed to the build tool.

When nothing is specified in this field, CLion uses default settings which depend on the selected environment. For example, the default setting for build processes running in parallel is -- -j max(cpucount * 0.8, cpucount - 2) for make and Ninja, while for Microsoft Visual C++ this option is not set and the field is empty.

Environment variables

You can pass additional environment variables to CMake generation and build via the Environment field of the CMake Settings dialog (navigate to Settings | Build, Execution, Deployment | CMake).

The overall impacting environment for CMake generation and build consists of:

Parent environment
To include parent environment, open the Environment Variables dialog by clicking or pressing Shift+Enter, and set the Include system environment variables checkbox. The values you specify additionally will be appended to system variables. Otherwise, when the checkbox is cleared, your custom values will overwrite the system ones.
Toolchain environment
These are the variables defined by the selected toolset (for example, vcvarsall.bat for MSVC or path variables like mingw/bin), or the variables from an environment initialization script.
You can use toolchain environment scripts to set CMake variables from a file.
CMake profile environment
Your custom variables specified in the Environment field.

You can reference existing variables, including the parent environment variables, using the $VAR$ syntax. Note that such references are case-sensitive: for example, PATH=xxx:$PATH$ for Linux/macOS and Path=xxx;$Path$ for Windows. Referencing existing variables is currently not available for remote toolchains (CPP-15693).

Last modified: 12 July 2024