CLion 2020.1 Help


Whatever you do in CLion, you do that in the context of a project. A project is an organizational unit that represents a complete software solution. It serves as a basis for coding assistance, bulk refactoring, coding style consistency, and so on.

CLion supports three project formats: CMake, JSON compilation database, and Gradle (see Project Formats for details).

Project files

A project in CLion is represented in the Directory Based Format. The project directory contains the .idea directory (not visible in the Project view of the Project tool window), with the following files:

  • .iml file that describes the project structure.

  • workspace.xml file that contains your workspace preferences.

  • A number of xml files. Each xml file is responsible for its own set of settings, that can be recognized by its name: projectCodeStyle.xml, encodings.xml, vcs.xml, and so on.

    Thus, for example, adding a new run/debug configuration and changing encoding will affect two different xml files. This helps avoid merge conflicts when the project settings are stored in a version control system and modified by the different team members.

All the settings files in the .idea directory should be put under version control except workspace.xml, which stores your local preferences. The workspace.xml file should be marked as ignored by VCS.

Project root directory

Any project in CLion should be encapsulated within the project directory, a root directory of which is referred to as a project root directory and contains all the project files and subdirectories, including configuration, data, source, and other files, related to the given project.

Project root directory contains one or more files of project description (which are also the inputs to the build system in case of CMake or Gradle): CMakeLists.txt for CMake, build.gradle for Gradle, and compile_commands.json for compilation database.

Path variables

Path variables are placeholders that stand for paths to resources linked to your project. They provide sharing flexibility as you do not have to reference a fixed location on your computer.

Path variables are useful if, for example, you have a third-party library defined at the project or module level, and it is stored outside the project directory or module content roots (for projects shared through VCS). Such a library is referenced by its absolute path and there is no guarantee that this path is the same on computers of your teammates. If you use a path variable, you make the path relative as each variable is configured on each computer individually.

In CLion, there are some pre-defined variables:

  • $USER_HOME$: stands for your home directory.

  • $PROJECT_DIR$: stands for the directory where your project is stored.

  • $MODULE_DIR$: stands for the directory that keeps module configuration files IML.

To configure path variables, in the Settings/Preferences dialog Ctrl+Alt+S, select Appearance & Behavior | Path Variables.

Path Variables dialog

Example: create a new path variable

For example, you have a third-party library that is not stored in your project directory. If you want to make sure that the path is correct on your teammates' computers after they update the project from VCS, you can create a new variable.

  1. In the Settings/Preferences dialog Ctrl+Alt+S, select Appearance & Behavior | Path Variables, and click the Add button.

  2. Enter the name of the new variable (for example, PATH_TO_LIB) and its value that points to the library location on your disk.

  3. Share the IML file through your version control system.

  4. After your teammates update their projects from VCS, they will change the PATH_TO_LIB variable value so that it points to the library location on their computers.

Ignore path variables

When you open a project, CLion checks if there are any unresolved path variables. If the IDE detects any, it will ask you to define values for them. If for some reason you do not want to do that (for example, if you are not going to use files or directories with the unresolved path variables), you can add them to the list of ignored variables.

You can also use the list of ignored variables if, for example, a program parameter passed to the JVM in a run/debug configuration has the same format as an internal ($SOME_STRING$) path variable. In this case, you can add this parameter to the list of ignored variables in order to avoid confusion. Enter SOME_STRING to the Ignored Variables field in the Path Variables dialog.

Last modified: 26 May 2020