I have a large-ish codebase which builds several dozen libaries and several executables.
The codebase is broken down hierarchically and libraries are build at pretty muc
Firstly, it enables you to use
and
, but that's not the main advantage. If you give CMake a project name then it will generate build targets for each of the sub-projects in their own directories. This means that whether you're using GNU Make, Eclipse CDT, XCode, or any of the other supported generators you can build sub-projects individually. For instance with GNU Make each sub-project has its own full build system from it's own directory.
You can access the current project name through PROJECT_NAME
, and the root project name by CMAKE_PROJECT_NAME
.
Edit: I've just realised the below will be standard CMake behaviour for any of its build targets whether they're projects or not. I'll keep it here for general information but it is not pertinent to the answer:
Assume I have a C++ library, and I can generate three binary executables; Main
and tests/test1
, and examples/ex1
. I can either run make in the directory I called CMake from with the ALL target, run make ex1
, or I can change directory to examples/
and build the examples with make
from that directory. This will build all of the dependent projects and libraries even if they're somewhere else in the directory structure but won't build Main
or tests/test1
or any libraries that they depend on that examples/ex1
doesn't. If I then run make from the main directory, it won't rebuild any of the libraries that examples/ex1
depends on unless their source has changed.