Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How to do "out-of-source" build properly with cmake?
There are two broad types of build environments - in-source and out-of-source. "In-source" means the compiled files will appear in the same directory as source files. "Out-of-source" means there is a dedicated directory for compilation results. It seems the latter one is more suitable for large projects, and it is also recommended by cmake.
Suppose my project contains several libraries, which have their own cmake fiels, CMakeLists.txt
.
I have two options - store build results for the libraries in the directories where libraries are, or in the directory of the project I am building.
project
possible place to put build results for libA and libB
project_1.cpp
project_2.cpp
libA
possible place to put build results for libA
libA_1.cpp
libA_2.cpp
libB
possible place to put build results for libB
libB_1.cpp
libB_2.cpp
Is there an option which is preferred by cmake?
Are there any obscure considerations which make one or the other option preferable?
2 answers
Use the following layout:
project/
CMakeLists.txt
project_1.cpp
project_2.cpp
libA
CMakeLists.txt
libA_1.cpp
libA_2.cpp
libB
CMakeLists.txt
libB_1.cpp
libB_2.cpp
In project/CMakeLists.txt
, you would have:
cmake_minimum_required(VERSION 3.16) # or newer
project(project)
# Set a global C++ version
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_CXX_EXTENSIONS NO)
# Add libraries to the build
add_subdirectory(libA)
add_subdirectory(libB)
# Create main project executable and link to libs
add_executable(main project_1.cpp project_2.cpp)
target_link_libraries(main PRIVATE libA libB)
Then both project/libA/CMakeLists.txt
and libB
will look like:
# Create "libX" (X=A or B) library
add_library(libX libX_1.cpp libX_2.cpp)
# Expose headers to internal build.
target_include_directories(
libX PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>)
Then, when building, you can select an out-of-tree directory for everything. CMake will automatically create a parallel directory structure (that's part of what add_subdirectory
does) for the sub-builds.
$ cd /path/to/project
$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -S . -B build
...
$ cmake --build build
...
$ ./build/main
...
As of CMake 3.19, you can use presets, which remove most needs for wrapper scripts that invoke CMake. See the documentation for more details.
Also, the build directory has never needed to exist before calling CMake; it will create it if it does not exist.
0 comment threads
Whenever I've worked with CMake-based projects, the structure has been something like this:
- project
- src <-------- typically this is a source control working directory
- CMakeLists.txt
- project_1.cpp
- project_2.cpp
- libA
- libA.cmake
- libA_1.cpp
- libA_2.cpp
- libB
- libB.cmake
- libB_1.cpp
- libB_2.cpp
- build <-------- CMake output goes here!
- runCMake.sh
- src <-------- typically this is a source control working directory
My runCMake.sh then looks like this:
#!/bin/sh
CMAKE= #wherever it's installed
BUILD=`pwd`/build
SRC=`pwd`/src
mkdir -p $BUILD
cd $BUILD
$CMAKE $DEBUG_OPTS $SRC
In other words, I have one build directory that stores the output of everything. Note that this directory serves to store three different types of things:
- CMake's own configuration files for this project (eg the CMakeCache).
- The project files that will be used by your build tool to actually build the software (eg Makefiles, or MSVC .sln and .proj files)
- The actual output of compiling and building.
I honestly don't know whether it is possible to store those three separately from each other and, if so, whether you can split up where the compilation output is stored. Nor, alternatively, how to split it up so that you have multiple build directories each of which stores those three things but only for a subset of your project (ie one for each library and one for your main application).
But I don't know why you'd want those things, either.
0 comment threads