課程

我們來解析為何在 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 的可見性有何不同、透過 target_link_libraries include 路徑如何傳遞給消費者，以及如何將公開 API（ include/）與內部實作標頭（ src/）分離。

我們會拆解在 CMake 中，target 之間透過 target_link_libraries 進行連結時是如何運作的，為什麼 # include 不會「自動帶入」實作， PRIVATE/ PUBLIC/ INTERFACE 有什麼差異，以及 CMake 如何沿著依賴圖傳遞（或不傳遞）建置需求。實作上，我們會組出一個包含 cli 與 calc 函式庫的範例，並學會診斷 undefined reference。