# 15.8 項目轉換為CMake的常見問題 我們總結一下，在這一章中所所學到的知識。 ## 代碼修改總結 在本章中，討論了如何將項目移植到CMake進行構建。我們以Vim項目為例，添加了以下文件: ```shell . ├── CMakeLists.txt └── src ├── autogenerate.cmake ├── CMakeLists.txt ├── config.h.cmake.in ├── libvterm │ └── CMakeLists.txt ├── pathdef.c.in └── testdir ├── CMakeLists.txt └── test.cmake ``` 可以在線查看修改： https://github.com/dev-cafe/vim/compare/b476cb7...cmake-support 為了簡單起見，我們省略了許多選項和調整，并將重點放在最重要的步驟上。 ## 常見問題 在結束討論之前，我們想指出一些遷移到CMake時常見的問題。 * **全局變量代碼異味**：這點適用于任何編程語言，CMake也不例外。跨CMake文件的變量，特別是從子到父`CMakeLists.txt`文件的“向上”傳遞的變量，這是明顯的“異味代碼”。通常，會有一種更好的方法來傳輸依賴關系。理想情況下，依賴項應該通過目標導入。與其將庫列表組裝成一個變量并在文件之間攜帶該變量，不如逐個鏈接到定義庫的地方。不是將源文件組裝成變量，而是使用`target_sources`添加源文件。當鏈接到庫時，在可用時使用導入的目標，而不是變量。 * **最小化順序的影響**：CMake不是一種聲明性語言，但是也不應該使用命令式范式進行處理。執行嚴格命令的代碼往往是脆弱的，這也與變量有關(見上一段)。一些語句和模塊的順序是必要的，但是為了實現健壯的CMake框架，我們應該避免不必要的順序強制。應該多使用`target_sources`、`target_compile_definition`、`target_include_directory`和`target_link_libraries`。避免使用全局范圍語句，如`add_definition`、`include_directory`和`link_libraries`，從而避免定義全局編譯標志。如果可能，為每個目標定義編譯標志。 * **不在build目錄之外生成文件**：強烈建議不要將生成的文件放在構建目錄之外。原因是生成的文件通常依賴于所選擇的選項、編譯器或構建類型。如果寫入原目錄樹，我們就放棄了用同一套源碼維護多個構建的可能性，并且會使構建步驟的重現復雜化。 * **盡可能使用函數，而不是宏**：它們的作用范圍不同，功能范圍也有限定。所有變量修改都需要顯式標記，這也向讀者展示了重新定義的變量。如果可以最好使用函數，必要時再使用宏。 * **避免shell命令**：Shell可能不能移植到其他平臺(如Windows)。可以使用CMake中的命令或函數。如果沒有可用的CMake等效函數，請考慮調用Python腳本。 * **Fortran中，注意后綴**：需要預處理的Fortran源文件是大寫的` .F90 `后綴。無預處理的源文件應該以`.f90`為后綴。 * **避免顯式路徑**：這條建議在定義目標和引用文件時都適用。當引用當前路徑時，可使用`CMAKE_CURRENT_LIST_DIR`。這樣做的好處是，當移動或重命名一個目錄時，構建不會出問題。 * **不應該在函數調用中進行模塊包含**：將CMake代碼模塊化是一個很好的策略，但是包含模塊不應該執行CMake代碼。相反，將CMake代碼封裝到函數和宏中，并在包含模塊之后顯式地調用這些函數和宏。當意外地多次包含模塊時，這條建議可以防止意外的副作用，并使執行CMake代碼模塊的操作更易讀。