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).
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.
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 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 .
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.
Enter the name of the new variable (for example,
PATH_TO_LIB) and its value that points to the library location on your disk.
Share the IML file through your version control system.
After your teammates update their projects from VCS, they will change the
PATH_TO_LIBvariable 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.