關閉。這個問題是基于意見的。它目前不接受答案。
想改進這個問題？更新問題，以便可以通過編輯這篇文章用事實和參考來回答它。
昨天關門。
改進這個問題我們過去使用的專案結構是代碼 預構建外部依賴項在 SVN 中進行源代碼控制。這很麻煩，因為外部庫很大并且不需要源代碼控制，因為它們是預構建的二進制檔案。
現在我們在 git 中有源代碼，并且預構建的二進制檔案在云中。克隆 repo 后，開發人員必須從云端下載此 lib 檔案夾。這里的問題是，如果您對 lib 進行更改，那么在開發人員重新下載此 lib 檔案夾之前，事情將無法正確構建。
我們的專案通常是為 Windows (MSVC) 開發的，但我們只是添加了 Linux (GCC Docker) 兼容性，并且將來 Linux 可能會成為主要版本。所以現在我們的庫每個都有一個 Windows 和一個 Linux 構建檔案夾。我們的開發環境是 Windows VSCode/WSL2/Docker for Linux。
此處處理外部依賴項的最佳常見做法是什么。我可以想到2種方法。
- 版本化云中的 lib 檔案夾并在構建期間檢查。如果開發人員 A 添加/更改此檔案并更新 CMakeLists 檔案，那么當開發人員 B 更新他的 git 存盤庫并嘗試構建時，CMake 可以看到他擁有的 libs 檔案夾的版本已經過時，并且會被告知去更新它。這是一點點努力，幾乎不會改變我們的流程。缺點是開發人員 A 必須記住在云和 cmake 檢查中更新版本。
- 在本地構建所有外部庫。使用 git 子模塊并讓 cmake 在構建主專案時構建所有依賴項。我假設有一種方法可以快取它，這樣它就不會經常重建（其中一些庫很大并且需要很長時間才能構建）。更多的作業，但更少的維護和額外的開發步驟需要。也可能更容易鏈接和包含反對。
uj5u.com熱心網友回復：
這里的問題是，如果您對 lib 進行更改，那么在開發人員重新下載此 lib 檔案夾之前，事情將無法正確構建。
清楚地表明您要使用的確切版本是您應該與源代碼一起跟蹤的內容的一部分。
我認為有一種方法可以快取它，因此它不會不斷重建（其中一些庫很大并且需要很長時間才能構建）
只要檔案不改變，就不需要重建任何東西。
所以，是的，如果你的專案具體依賴于外部庫，那么 git 子模塊聽起來確實很有吸引力。
另請注意，其他構建系統（如介子）對樹內依賴項專案有更清晰的理解，可以檢查您的系統是否安裝了依賴項的版本，如果沒有合適的版本，請下載，如有必要，自行構建。
因此，正如您所說，第二種選擇可能是最容易維護的解決方案。
然而，我來自免費和開源的背景，我的用戶和他們的平臺是多種多樣的，Linux 發行版有嚴格的指導方針，不打包相同依賴項的 N 個副本。因此，這將使將此類軟體包上游到 debian、Ubuntu、Fedora、Arch 變得更加困難……。所以，對我來說，情況是這樣的：如果我們想在一個專案中使用一個庫，我們會非常清楚地定義那個庫的最舊版本是什么可以作業的。在一個發布周期內，我們不能增加所需的版本。
比如說，我們發布了一些軟體的 2.0.0。CMake 檔案定義了我們支持的庫版本。“發布”軟體意味著我們向開發人員和用戶保證，我們 2.ab 系列中的下一個錯誤修復/功能擴展版本仍然構建在相同的系統上 - 并且包括可能安裝在那里的相同庫。因此，如果 2.0.0 構建在您的計算機上，那么 2.0.1 和 2.9.0 也將構建。需要新版本的外部依賴項的開發只能發生在 git 分支上，該分支并不意味著進一步的 2.ab 版本，而是針對最終的 3.0.0。在為該 3.0.0 版本選擇最低依賴版本時，我們會查看我們支持的作業系統上通常可用的內容。例如，如果我的時間表是 3.0.0 在 2022 年或 2023 年發布，
無論如何，通過這些標準打包渠道無法在可接受的版本中提供的所有內容都需要在本地構建。事實證明，如果您不是瘋狂進步并且不嘗試支持 5 年的 Linux，那么您需要在本地構建的專案數量非常少。
在 Windows 上，Microsoft 無法提供一種真正明智的方式來下載實際在不同應用程式軟體之間共享的二進制共享庫包，這使您基本上受到了阻礙。因此，在 Windows 系統上，您要么在本地進行所有構建，要么使用第三方分發平臺相關包的方式，如柯南。
不管你怎么做，你會讓你的構建盡早失敗，并清楚地表明找到的庫版本不夠新。CMake 讓這一切變得簡單；它的find_package命令以最低版本作為引數。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/504075.html