Exercises — CMake — CMakeLists.txt, add_executable, add_library, target_link_libraries

• add_executable(name sources...) → a program you can run (calc, calc.exe).
• add_library(name [STATIC|SHARED|INTERFACE] sources...) → code other targets link against.

Why: an executable has an entry point (main) and is the end of a link chain; a library is a reusable unit that something else pulls in.

• target_link_libraries — the command that declares "one target depends on another".
• calc — the consumer target (does the linking).
• PRIVATE — the propagation keyword (who inherits the dependency past calc).
• mathlib — the dependency being linked in.

False. It must be the first command, before project(). It fixes CMake's policy behaviour so the build is reproducible; placing it later triggers a hard error/warning.

cmake_minimum_required(VERSION 3.16)
project(Game LANGUAGES CXX)
add_executable(game main.cpp)

Three lines, in this order: version pin → project (sets up the C++ compiler & ${PROJECT_SOURCE_DIR}) → target. Anything less either errors (no version) or warns (no project).

cmake_minimum_required(VERSION 3.16)
project(Sim LANGUAGES CXX)
 
add_library(physics STATIC physics/vec.cpp)
target_include_directories(physics PUBLIC physics)   # PUBLIC = users see it too
 
add_executable(sim sim/main.cpp)
target_link_libraries(sim PRIVATE physics)

Why PUBLIC on the include dir? vec.h is in physics's interface, so anyone linking physics must be able to find it. PUBLIC makes that include directory flow into sim automatically. Why PRIVATE on the link? sim is an executable — nothing links against an executable, so propagating past it is meaningless; PRIVATE is the minimal correct choice. (On Header files and Include Guards — vec.h still needs its own include guard regardless.)

add_library(physics INTERFACE)                        # no sources
target_include_directories(physics INTERFACE physics) # only users need it
add_executable(sim sim/main.cpp)
target_link_libraries(sim INTERFACE physics)

An INTERFACE library compiles nothing; its whole job is to hand include dirs/flags to users. Everything about it is INTERFACE because physics itself has no implementation to serve.

Yes to both. core → util is PUBLIC, so util is part of core's interface. When app links core, the PUBLIC (interface) portion of core — which includes util and util's include dirs — flows one step further into app. Trace it on figure s01: follow the yellow PUBLIC arrow core→util, then the app→core edge — the PUBLIC edge keeps propagating. Link order (util before core) is computed by CMake from this graph; you never spell it out.

• Does app link util? Yes — a STATIC private dependency's object code is still needed at final link time (the symbols core.cpp calls must resolve), so util is pulled into the final binary. Linkage as code still happens.
• Does app see util's headers? No — PRIVATE hides util's include dirs inside core. app cannot #include util's headers, which is correct: app never asked for util.

This is the key distinction: PRIVATE hides the usage requirements (headers/flags), not the raw object code a static link physically needs.

No. A SHARED library (.so/.dll) is loaded at runtime, never copied in. app records a reference to mathlib and the loader finds it when app starts. PRIVATE vs PUBLIC only affects whether mathlib's headers/flags propagate to app's consumers — it does not change static-vs-dynamic copy behaviour. See Static vs Dynamic Linking.

cmake_minimum_required(VERSION 3.16)
project(Server LANGUAGES CXX)
 
add_library(logger  STATIC logger.cpp)
target_include_directories(logger PUBLIC logger)
 
add_library(crypto  STATIC crypto.cpp)
target_include_directories(crypto PUBLIC crypto)
 
add_library(network STATIC network.cpp)
target_include_directories(network PUBLIC network)
target_link_libraries(network PUBLIC  logger)   # logger appears in network.h
target_link_libraries(network PRIVATE crypto)   # crypto only inside network.cpp
 
add_executable(server main.cpp)
target_link_libraries(server PRIVATE network)

Trace the requirement: server → network (PRIVATE, fine — server has no users). network → logger is PUBLIC, so logger's headers flow through network into server ⇒ server can #include "logger.h". ✅ network → crypto is PRIVATE, so crypto's include dir stays inside network ⇒ server cannot see crypto.h. ✅ (crypto's object code is still linked into the final binary because it's STATIC.)

find_package(fmt REQUIRED)                       # brings in the fmt::fmt target
target_link_libraries(logger PUBLIC fmt::fmt)    # fmt types are in logger.h -> PUBLIC

Because fmt appears in logger's header, it is part of logger's interface → PUBLIC. It then rides the PUBLIC chain logger → network → server, so server transparently gets fmt too. See Package Management find_package.

Why it breaks: include_directories() and link_libraries() are directory-scoped, non-target commands. They apply to every target declared afterward in that directory — including b. So b links mathlib it never asked for, and any global flag leaks into unrelated targets. This is exactly the "leak" the parent note warns about. Correct rewrite (target-centric):

add_library(mathlib STATIC math/add.cpp)
target_include_directories(mathlib PUBLIC math)
 
add_executable(a a.cpp)
target_link_libraries(a PRIVATE mathlib)   # only a links it
 
add_executable(b b.cpp)                    # b stays clean

Now each target declares exactly its own dependencies — no leakage.

• Design A: shared.cpp is compiled once per executable that lists it → 3 compilations.
• Design B: shared.cpp lives in one library target → compiled 1 time; x, y, z just link the resulting object.
• Saving: $3-1=2$ redundant compilations avoided (a $\frac{2}{3}\approx 66.7\%$ reduction). This is the concrete cost of the "just add the .cpp everywhere" mistake — and it grows linearly with the number of consumers.

app names only core directly. Because every edge is PUBLIC, the interface flows all the way down: app links core, util, base → 3 libraries total, of which 2 (util, base) are transitive. Follow the unbroken chain of yellow PUBLIC arrows on figure s02 — one broken (PRIVATE) link anywhere would stop the flow at that point.

• PRIVATE hides what but still links what (static)? ::: hides headers/flags; still links object code.
• Header-only lib keyword? ::: INTERFACE everywhere.
• Dependency in your header ⇒ keyword? ::: PUBLIC.
• shared.cpp in 3 executables vs 1 library — compilations? ::: 3 vs 1.
• Who computes link order? ::: CMake, from the dependency graph.