Project

Basics

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, etc.

Project files

A project in CLion is represented in the Directory Based Format. A project directory is marked with icon.

Such project directory contains the .idea directory, 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 etc.

  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 the workspace.xml, which stores your local preferences. The workspace.xml file should be marked as ignored by VCS.

.idea directory is not visible in the Project view of the Project Tool Window.

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.

As a rule, the project root directory also contains CMakeLists.txt file, which is an important element of CMake build system and describes the project configuration, source files and targets.

Note: when a source or header file is not included into either CMake target and is not located under the source or library roots, CLion notifies you about it:

You can experience an incorrect behavior of such features like syntax highlighting, refactoring, code navigation etc. for such a file until you specify that file as a project one explicitly. To do that use one of the following approaches:

1. When the source files that don't belong to any target are located within the project root, you should add them to a target. Use add_executable () or add_library () CMake commands depending on the target type. Let's consider it for our example.
   The above screenshot reflects condition when add executable () contains only the main.cpp file and knows nothing about library.cpp:
   add_executable (calendar_run main.cpp)
   Here, you should add the non-project sources to the list of source files, as follows:
   add_executable (calendar_run main.cpp library.cpp)
2. When a directory that contains the non-project library sources is located within the project root, you can mark this directory as a library: in the Project tool window, right click the desired directory and select Mark Directory As | Library Files from the context menu.
3. For the library files located outside the project root, specify the header search paths so that the IDE can index the respective directories and provide code completion and navigation facilities on #include statements:
   
   include_directories( ${MY_EXTERNAL_SOURCE__DIR})
   For more details, refer to our Quick CMake Tutorial.

Upon any of these actions, the system will prompt you to reload CMake project if automatic reload is not enabled.