爲什麼cmake文件GLOB是邪惡的？

CMake的醫生說有關命令file GLOB：爲什麼cmake文件GLOB是邪惡的？

我們不建議使用GLOB收集源文件的列表，從你的源代碼樹。如果在添加或刪除源時未更改CMakeLists.txt文件，則生成的生成系統無法知道何時要求CMake重新生成。

在網絡上的幾個討論線程，其中通配源文件是邪惡的。

然而，爲了使構建系統知道源已被添加或刪除，這足以說

touch CMakeLists.txt

，對嗎？

然後，這比編輯CMakeLists.txt插入或刪除源文件名更省力。也不難記得。所以我沒有看到有任何理由建議對file GLOB。

這個說法有什麼問題？

來源

2015-09-05 Joachim W

另請參閱討論[這裏]（http://stackoverflow.com/questions/30949452/cmake-ninja-attempting-to-compile-deleted-cpp-file/31183245）。正如我在我的回答中所描述的那樣，我使用了一種混合方法：將所有源文件列在'CMakeLists.txt'文件中（也因爲有時我會爲不同的構建配置精選源文件）和頭文件的globul（出於方便讓他們參加VS項目）。我提出了一個解決方法，例如'git'用'configure_file（$ {CMAKE_SOURCE_DIR}/.git/index $ {PROJECT_BINARY_DIR} /git_index.tmp）''。 – Florian

問題是，當你不是一個人在一個項目上工作。

假設項目有開發商A和B.

一個增加了一個新的源文件x.c。他沒有更改CMakeLists.txt並在完成x.c之後提交。

現在B則一個git pull，由於沒有出現過修改的CMakeLists.txt，CMake的，系統不再運行和B有鏈接錯誤編譯時，因爲x.c還沒有被添加到它的源文件列表。

來源

2015-09-05 10:33:30

好點，謝謝。在我接受這個答案之前（並且可能開始考慮解決方法），請讓我等一等，看看是否會出現更多問題。 –

當然，我認爲這是一個相當懸而未決的問題，而且多人會有經驗分享有關globbing的經驗。我遺憾地不知道解決方法，我有一個大的項目（> 500個源文件），我從globbing遷移回文件列表，因爲其他開發人員總是會抱怨說構建在他們的機器上破壞，即使它沒有在CI服務器上休息。 –

@ Jean-MichaëlCelerier解決方法＃1：在git pull之後運行cmake（嚴重），解決方法＃2：在'CMakeLists'中，將globbing的結果寫入文件（有條件地，如果不存在）在源代碼控制下。使'CMakeLists'包含該文件。在添加新文件時，刪除globresult文件。 –

這不是固有邪惡 - 它有優點和缺點，在這裏StackOverflow的this answer覆蓋得相當好。但是如果您不小心使用它，最終可能會忽略依賴性更改，並且需要對代碼庫的大部分進行簡潔重建。

我個人贊成在較小的項目或較大的某些子目錄中使用它，以避免必須手動輸入每個文件到構建文件中。 編輯：我的偏好已改變，我目前傾向於避免它。

來源

2016-02-15 22:48:04 einpoklum

有許多微妙的情況，在某些情況下，你必須做乾淨的構建作爲唯一的救援。我不認爲它適合大型項目 – Fei

@Fei：這取決於你正在建造什麼。在一個大型項目中，您可能會爲其中的一小部分使用球體，但這對於整個項目來說肯定不合適。 – einpoklum

爲什麼cmake文件GLOB是邪惡的？

回答

相關問題