我們有一個項目需要連接libcurl和libxml2以及其他庫。我們似乎有管理這些depencies兩個基本策略：可以假定哪些依賴關係可以安裝在構建機器上？
要求每個開發人員安裝下的「正常」位置，例如那些庫/usr/lib或
將這些庫的源文件包含在項目源代碼樹的專用文件夾下。
方法1要求每個人都確保這些庫安裝在他們的系統上，但似乎是許多開源項目所使用的方法。在這樣的項目中，構建將檢測到這些庫缺失並將失敗。
方法2可能會使項目樹在某些情況下難以管理，並使編譯時間更長。另外，這種方法顯然可能會被採用太多。例如，我不會把編譯器放在項目樹下（對吧？）。
什麼是外部依賴的最佳實踐？可以/應該要求每個開發人員安裝某些庫來構建項目嗎？或者認爲在項目樹中包含所有的依賴關係會更好？
不要打擾他們在您的代碼中的確切位置。找到它們應該由使用過的編譯器/鏈接器（或者用戶通過設置變量）來處理，如果它們很常見的話。對於非常罕見的依賴關係（或具有自定義/修改文件的依賴項），您可能希望將它們包含在源代碼中（如果可能，則由於許可等原因）。
如果您希望更方便一些，您應該使用一些腳本（例如configure或CMake）來設置/創建正在使用的構建文件。例如CMake允許你設置不同的包（在你的例子中爲libcurl和libxml2）爲可選和必需的。在構建項目時，它會嘗試找到這些項目，如果失敗，它會詢問用戶。這是一個額外的步驟，可能會使構建更加麻煩，但它也將使下載更快（更小的源代碼）以及更新更容易（因爲您只需重建程序）。
所以一般我會遵循方法1，如果有特殊的/稀有/定製的東西被使用，方法2.
正常的方法是有相應的依賴關係，並讓開發者安裝它們。稍後，如果項目被分組到.deb或.rpm，這些數據包將需要安裝相應的庫，則源數據包將具有-devel數據包作爲依賴關係。
最佳做法是不包括在你的源代碼樹的外部庫 - 相反，在項目根目錄中包含一個名爲INSTALL的文本文件，該文件提供了有關構建項目的說明，幷包含了庫依賴項的列表，其中包括最低版本。