Simplify Dependency Propagation with CMake Interface Libraries

The duplication problem in large CMake projects

When a project grows, many targets end up repeating the same boilerplate: adding an include directory, setting a compile definition, or linking a system library. For example, every executable that uses a header‑only math utility might need:

target_include_directories(app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/math_utils/include)
target_compile_definitions(app PRIVATE USE_MATH_UTILS)
target_link_libraries(app PRIVATE pthread)

If the utility’s requirements change, each target must be edited manually, increasing the chance of inconsistencies.

Thesis: interface libraries centralize usage requirements

An interface library is a special CMake target that contains no source files. Instead, it declares usage requirements—include paths, definitions, and link dependencies—that are automatically propagated to any target that links against it. By wrapping a component’s requirements in an interface library, consumers need only a single target_link_libraries call.

Worked example: a header‑only math utility that needs pthread

Assume a directory layout:

project_root/
├─ CMakeLists.txt
├─ math_utils/
│  ├─ include/
│  │  └─ math_utils.h
│  └─ src/   (empty – the library is header‑only)
└─ apps/
   └─ calc.cpp

First, declare the regular library target for the headers (even though it has no sources, we keep it as a normal target so it can be versioned or have properties):
# project_root/CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(Demo LANGUAGES CXX)

add_library(math_utils INTERFACE)
target_include_directories(math_utils INTERFACE
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/math_utils/include>
  $<INSTALL_INTERFACE:include>)
# The utility needs pthread at compile time
target_compile_definitions(math_utils INTERFACE USE_MATH_UTILS)
target_link_libraries(math_utils INTERFACE pthread)

# Consumer executable
add_executable(calc apps/calc.cpp)
target_link_libraries(calc PRIVATE math_utils)

Notice that calc only links to math_utils. The interface library’s INTERFACE scopes cause CMake to add the include directory, the definition, and the pthread link flag automatically.
Trade‑off and limitation
Interface libraries cannot contain source files, so they cannot provide compiled objects. If your component actually needs to be built (e.g., a source‑based library), you must still create a regular STATIC or SHARED target for the implementation and link that separately. The interface library is purely a conduit for usage requirements.
Verification steps

Create a minimal build directory: cmake -B build -S .
Build with verbose output: cmake --build build --verbose
Inspect the compile line for calc; you should see something like -I/path/to/project_root/math_utils/include -DUSE_MATH_UTILS and the link line containing -lpthread.
Remove target_link_libraries(calc PRIVATE math_utils) and rebuild; the build should fail with either a missing header (math_utils.h: No such file or directory) or an undefined reference to a pthread symbol, confirming that the interface library was indeed providing those requirements.

These checks let you confirm that the interface library is correctly propagating its interface without assuming any particular build system output.
Actionable closing
Adopt interface libraries for any header‑only or dependency‑only component in your CMake project. Replace repetitive target_include_directories, target_compile_definitions, and target_link_libraries calls with a single link to the interface library. Keep the implementation target separate when sources exist, and verify propagation with the verbose build steps shown above. This reduces boilerplate, centralizes requirement changes, and makes your CMakeLists.txt easier to maintain.