Question bank — CMake — CMakeLists.txt, add_executable, add_library, target_link_libraries

False. CMake is a meta build-system — it generates native build files (Makefiles, Ninja files, VS projects), and the generator then invokes the actual compiler. See Makefiles for what it produces.

False. CMake builds a dependency graph and computes link order itself; you only declare what depends on what. Raw g++ is order-sensitive, but CMake is not.

False — PRIVATE is exactly right. Nothing links against an executable, so propagation past it is meaningless; PRIVATE is the correct minimal choice, not an error.

Mostly true for the commands, false for behaviour. You write the same TLL either way, but STATIC (.a/.lib) is copied into the binary while SHARED (.so/.dll) loads at runtime — see Static vs Dynamic Linking.

False. include_directories() is directory-scoped and leaks into every target in that directory; the target_* form attaches include dirs to one target with a controlled propagation keyword.

False. An INTERFACE library has no implementation by definition — its whole purpose is to carry usage requirements (flags, include dirs) to users, e.g. a header-only lib.

False. Without project() CMake auto-injects a default project(Project) enabling C and C++, so it warns you and — crucially — until it runs, variables like ${PROJECT_SOURCE_DIR}, ${PROJECT_NAME}, ${CMAKE_CXX_COMPILER} and the whole toolchain/ABI detection are not set up. Always declare it explicitly.

False. cmake --build build detects the changed script and re-triggers the configure phase automatically before building.

False in practice. It compiles, but the file is recompiled per target and there's no single place defining its interface — wrap it in add_library once instead.

The propagation keyword (PUBLIC/PRIVATE/INTERFACE). This "plain" (keyword-less) signature is a legacy holdover that fills the old LINK_INTERFACE_LIBRARIES variable and can't express per-scope propagation; CMake kept it only for backward compatibility and forbids mixing plain and keyword forms on one target, so modern code must pick a keyword to get well-defined PUBLIC/PRIVATE/INTERFACE flow.

The API violation: an INTERFACE library is not allowed to list any sources at all (not even a header) in this signature — CMake rejects it. INTERFACE libraries have no build step, so you write just add_library(hdronly INTERFACE) and attach the header directory with target_include_directories(hdronly INTERFACE include). The keyword you use to link it (INTERFACE, so users get the headers) is a separate, downstream question — don't let it distract from the fact this line won't even configure.

mathlib never exported its include dir. Add target_include_directories(mathlib PUBLIC math). PUBLIC vs PRIVATE matters here: add.h is part of mathlib's public interface (users #include it), so the dir must ride the interface door out to calc. With PRIVATE, the dir would stay inside mathlib's own compilation and calc still couldn't find add.h. See Header files and Include Guards.

cmake_minimum_required must be first — it sets policy behaviour that affects how every later command (including project()) is interpreted; placing it later triggers a hard error/warning.

There are no generated build files yet — you must configure first with cmake -S . -B build, then build. The two phases are configure then build.

It should be PRIVATE. Since fmt doesn't appear in mathlib's public header, marking it PUBLIC needlessly forces every user of mathlib to also see fmt — bloated, over-coupled builds.

CMake's behaviour ("policies") changes between versions; declaring a minimum makes builds reproducible and lets CMake pick the right default behaviours instead of guessing.

target_* commands scope settings to a single target with a propagation keyword, so flags don't leak into unrelated targets — the essence of "target-centric" modern CMake.

It controls transitive propagation. Wrong choice = downstream targets either miss required headers/flags (broken) or inherit ones they don't need (bloated, over-coupled).

So generated junk (Makefiles, object files, cache) never pollutes your source tree, keeping the repo clean and letting you delete build/ to start fresh.

Because it builds a full dependency graph and topologically orders the linker — this eliminates the fragile, order-sensitive -lcore -lutil bugs you'd hit hand-writing linker commands.

find_package locates a dependency portably across machines and hands you targets with correct include dirs and flags already attached — see Package Management find_package. Hard-coded paths break on other systems.

Because it doesn't run the compiler itself — it generates the input for a real build tool (Make, Ninja, MSBuild), one layer above the actual build.

Yes. PUBLIC makes util part of core's interface, so it flows transitively into app, including util's include dirs. (Trace the arrow in the propagation diagram above.)

No, and correctly so. PRIVATE hides util inside core's .cpp; app links core but never sees util's headers, which is right since it shouldn't need them.

It adds no compiled code but forwards usage requirements (flags, include dirs, transitive deps) to anyone who links it — the whole point of an INTERFACE/header-only target.

CMake cannot topologically order a genuine cycle for STATIC libs and will error/require workarounds; the dependency graph must be acyclic (a DAG).

Generally no — you link against libraries, not executables; an executable is a terminal node, so nothing propagates from it.

CMake needs to know it's generated (e.g. via a custom command output) or configure fails; a plain missing file is treated as an error since nothing produces it.

No. All your configuration lives in CMakeLists.txt; build/ is fully regenerable — deleting it just forces a clean re-configure.