课时

我们来解析为什么在 C++ 中构建很快会成为一项独立的任务：从多文件项目，包含 .cpp/ .hpp 和 include/, src/ 文件夹，到典型的编译和链接错误。展示“指挥者”（对编译器和链接器的协调）的作用，解释跨平台性（Visual Studio / Make / Ninja / Xcode），并确立正确的模型： CMake 是对项目及其 targets 的描述，而不是“又一个编译器”。

解析 C++ 的 CMake 项目“骨架”：为什么需要文件 CMakeLists.txt， project(...) 命令做了什么，如何通过 add_executable(...) 声明目标，为什么通过 target_compile_features(...) 固定标准很重要，以及如果忘记把 .cpp 加入构建时，如何诊断典型的链接错误 undefined reference。

我们分析为什么像 CMAKE_CXX_FLAGS 和 include_directories 这样的“全局魔法”难以扩展，以及如何转向严格的基于 target 的做法：通过 target_compile_features（例如 cxx_std_23）设置标准，通过 target_compile_definitions 设置宏，通过 target_compile_options 设置警告和编译器选项。单独固定可见性（ PRIVATE/ PUBLIC/ INTERFACE）的概念，并构建一个迷你项目 MiniCalc。

我们来讲解 CMake 如何通过 target_include_directories 为特定 target 指定 include 路径：为什么在没有配置的情况下编译器“看不到”头文件、 PRIVATE/ PUBLIC/ INTERFACE 这些可见性有何区别、include 路径如何通过 target_link_libraries 对消费者产生传递性，以及如何将公共 API（ include/）与实现的内部头文件（ src/）分离。

我们来拆解在 CMake 中如何通过 target_link_libraries 链接各个 target，为什么 # include 不会“顺带带上”实现， PRIVATE/ PUBLIC/ INTERFACE 有什么区别，以及 CMake 如何沿着依赖图传递（或不传递）构建要求。实践部分会搭建一个包含 cli 和 calc 库的示例，并学习如何诊断 undefined reference。