The path to the top level of the source tree. This is the full path to the top level of the current CMake source tree. For an in-source build, this would be the same as CMAKE_BINARY_DIR .
The path to the binary directory currently being processed. This is the full path to the build directory that is currently being processed by cmake.
Add a subdirectory to the build. Adds a subdirectory to the build. The source_dir specifies the directory in which the source CMakeLists.
CMakeLists. txt is placed at the root of the source tree of any application, library it will work for. If there are multiple modules, and each module can be compiled and built separately, CMakeLists. txt can be inserted into the sub folder.
The variables CMAKE_CURRENT_SOURCE_DIR
and CMAKE_CURRENT_LIST_DIR
may refer to different directories for a CMake list file that is included by another file with the include command. E.g., if a CMakeLists.txt
is present in a directory project
and contains the following directive
include(src/CMakeLists.txt)
then while src/CMakeLists.txt
is being processed CMAKE_CURRENT_LIST_DIR
will refer to project/src
whereas CMAKE_CURRENT_SOURCE_DIR
still points to the outer directory project
.
CMAKE_CURRENT_LIST_DIR
comes in handy when you need to locate resource files like template files or batch scripts that are located next to the CMakeLists.txt
file currently being processed.
Note: When using the add_subdirectory()
command rather than include()
, the behavior is different, and when src/CMakeLists.txt
is being processed, both variables will point to project/src
.
Definitions
CMAKE_SOURCE_DIR
: Topmost folder(source directory) that contains a CMakeList.txt file. The value never changes in different scopes.
PROJECT_SOURCE_DIR
: The nearest folder that contains CMakeList.txt file, with its own scope, that contains project() command.
CMAKE_CURRENT_SOURCE_DIR
: The nearest folder that contains CMakeList.txt file with its own scope. (File do not need to contain project() command)
CMAKE_CURRENT_LIST_DIR
: The folder that contains currently processed CMakeList.txt or .cmake file.
What I mean by its own scope is related to scoping rules. While include(file) command is not creating a new scope, add_subdirectory is creating a new scope which affects the PROJECT_SOURCE_DIR and CMAKE_CURRENT_SOURCE_DIR values.
Example
Let project structure be like below:
A/
=> CMakeList.txt
=> B/
=> CMakeList.txt
and let us assume we are printing all cmake variables by putting message command to CMakeList.txt file in subfolder B.
CMAKE_SOURCE_DIR
will be source directory which is "path to project/A".
PROJECT_SOURCE_DIR
will be "path to project/A", because include command does not create a new scope and the nearest CMakeList.txt file that has its own scope and contains project command is in folder A.
CMAKE_CURRENT_SOURCE_DIR
will be "path to project/A", because include command does not create a new scope and the nearest CMakeList.txt file that has its own scope is in folder A.
CMAKE_CURRENT_LIST_DIR
will be "path to project/A/B", because currently processed file is in subfolder B.
CMAKE_SOURCE_DIR
will be source directory which is "path to project/A".
PROJECT_SOURCE_DIR
will be "path to project/A/B", because add_subdirectory command creates a new scope and the nearest CMakeList.txt file that has its own scope and contains project command is in subfolder B.
CMAKE_CURRENT_SOURCE_DIR
will be "path to project/A/B", because add_subdirectory command creates a new scope and the nearest CMakeList.txt file that has its own scope is in subfolder B.
CMAKE_CURRENT_LIST_DIR
will be "path to project/A/B", because currently processed file is in subfolder B.
Reference: https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/Useful-Variables
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With