有一天，我在虛擬機中安裝了一個unbuntu安裝程序，然後去收集我認爲在C++中編程moslty所需的工具和庫。Linux編程環境配置
我雖然有一個問題，在哪裏放的東西，如第三方代碼庫等。從我所知，很多源代碼分發的假設，有很多他們的依賴已經安裝在某個位置，並承擔很多工具也安裝在特定的位置。
舉一個我目前在windows上做的例子，我有一個目錄，我保留所有的源代碼。 C：\代碼。在這個目錄中，我有一個所有第三方庫的目錄，c：\ code \ thirdparty \ libs。通過這種方式，我可以輕鬆地爲我編寫或想要編譯的任何項目的所有依賴項設置相對路徑。我有興趣設置一個Linux編程環境的原因是，似乎工具和庫依賴問題已經得到有效解決，例如從源代碼構建OpenSSH很容易。
所以我一直在尋找的是一個體面的對話，當我試圖在linux上對我的項目和庫進行編程時，我很容易維護和易於使用。
對於庫/包括......
/usr/local/lib
/usr/local/include
簡短的回答：不做「堆在本地dir代碼「的東西。
長的答案：不要在本地dir中做一堆「代碼」的事情，因爲這將是噩夢保持最新，如果你決定分發你的代碼，它將是噩夢它適合任何體面的發行。
只要有可能，堅持發行版中的庫（Ubuntu有20000+包，它應該有大部分你需要預先包裝）。當沒有軟件包時，可以手動安裝到/ usr/local（但請參閱上面有關升級的內容並且不要這樣做）。
更好的是，使用「stow」或「installwatch」（或兩者）安裝到每個庫目錄（/ usr/local/stow/libA-ver123），然後將文件從/ usr/local或/ usr /（stow做simlinking部分）。或者只是爲你的發行版打包lib。
可能的代碼針對系統/發行版提供的庫。這使得在該發行版上發佈產品變得最容易。
但是，如果你正在構建一個商業應用程序，因爲有這麼多的Linux發行版，這意味着你必須爲每個發行版維護大量不同的應用程序版本。這不一定是壞事，因爲這意味着你可以更乾淨地與發行版的包管理系統集成。
但是在不能這樣做的情況下，應該很容易下載每個第三方依賴關係的源代碼，並將該依賴關係的構建集成到與您的可執行文件鏈接的靜態庫中。這樣你就可以確切地知道你連接的是什麼，但是卻有膨脹你的可執行文件大小的缺點。如果您需要發行版未提供的特定庫（或版本），也可能需要此功能。
如果您希望您的代碼構建在各種不同的Unix系統上，那麼您可能會明智地考慮GNU autoconf和automake。這些幫助你爲你的項目構建一個configure腳本和makefile，這樣它就可以建立在任何Unix系統上。
另請參閱pkg-config，它現在在Linux發行版上使用很多，可以幫助您包含並鏈接到正確的庫（用於支持pkg-config的庫）。
如果你使用Subversion來管理你的來源有一個「慣例」，大多數顛覆倉庫用來管理他們自己的代碼和「供應商」的代碼。
大多數svn軟件倉庫都有一個「供應商」樹（隨樹幹一起分支，樹枝分支&）。這是所有第三方供應商代碼的首選。在該目錄中，您使用了每個庫的目錄。例如：
branches/
tags/
trunk/
vendor/somelib
vendor/anotherlib
下面的每個這些庫的是每個庫的版本和最先進的最新版本在你的倉庫「當前」目錄的目錄。在這裏
libs目錄應該
主幹/來源＃所有的代碼在這裏 主幹/林達＃所有供應商代碼：
vendor/somelib/1.0
vendor/somelib/1.1
vendor/somelib/current
那麼你的項目的樹應當設置是這樣的爲空，但它必須與它相關svn:externals元數據，通過：
svn propedit svn:externals trunk/libs
此屬性的內容是一些沿線的東西（假設顛覆1.5）：
^/vendor/somelib/current somelib
^/vendor/anotherlib/1.0 anotherlib
這意味着，當你結帳代碼顛覆還檢查出你的供應商庫到你的軀幹/ libs目錄。所以，當檢查了它看起來像這樣：
trunk/source
trunk/libs/somelib
trunk/libs/anotherlib
這在Subversion Book描述（可能是好多了）。特別是關於處理vendor branches和externals的部分。