前几天我在虚拟机中安装了一个 Ubuntu，然后去收集我认为主要用 C++ 进行编程所需的工具和库。
但是我遇到了一个问题，将诸如 3rd 方源库之类的东西放在哪里。据我所知，很多源代码发行版都假设它们的许多依赖项已经安装在某个位置，并假设很多工具也安装在特定位置。
举一个我目前在 Windows 上所做的例子，我有一个目录来保存所有源代码。C:\code. 在这个目录中，我有一个所有 3rd 方库的目录，c:\code\thirdparty\libs. 这样，我可以轻松地为我编写或遇到并希望编译的任何项目的所有依赖项设置相对路径。我对设置 linux 编程环境感兴趣的原因是，似乎工具和库依赖问题都得到了有效解决，例如从源代码构建 OpenSSH 变得容易。
因此，当我尝试在 linux 上组织我的项目和库时，我一直在寻找一个体面的约定，它易于维护和使用。
简短的回答：不要做“本地目录中的大量代码”的事情。
长答案：不要做“本地目录中的大量代码”的事情，因为保持最新状态将是一场噩梦，如果您决定分发您的代码，将其打包以获取任何体面的代码将是一场噩梦分配。
只要有可能，请坚持使用发行版中提供的库（ubuntu 有 20000 多个数据包，它应该预先打包了您需要的大部分内容）。当没有软件包时，您可以手动安装到 /usr/local （但请参阅上面关于升级的内容，不要这样做）。
更好的是，使用“stow”或“installwatch”（或两者）安装到每个库目录（/usr/local/stow/libA-ver123），然后将文件从那里符号链接到 /usr/local 或 /usr/（stow做simlinking部分）。或者只是为您的发行版打包 lib。
对于库/包含...
/usr/local/lib
/usr/local/include
尽可能针对系统/发行版提供的库的代码。这使得在该发行版上发布产品变得最容易。
但是，如果您正在构建一个商业应用程序，因为 Linux 发行版的风格如此之多，这可能意味着您必须为每个发行版维护大量不同的应用程序构建。这不一定是坏事，因为这意味着您可以更干净地与发行版的包管理系统集成。
但是在你不能这样做的情况下，下载你拥有的每个 3rd 方依赖项的源代码并将该依赖项的构建集成到一个链接到你的可执行文件的静态库中应该是相当容易的。这样，您就可以确切地知道要链接的内容，但缺点是会增大可执行文件的大小。如果您需要发行版未提供的特定库（或版本），这也可能是必需的。
如果您希望您的代码构建在各种不同的 Unix 系统上，那么您可能明智地研究 GNU autoconf和automake。这些可以帮助您构建configure脚本并makefile为您的项目构建脚本，以便它可以构建在几乎任何 Unix 系统上。
还可以查看现在在 Linux 发行版上大量使用的pkg-config，以帮助您包含和链接到正确的库（对于支持 pkg-config 的库）。
如果您使用颠覆来管理您的源代码，那么大多数颠覆存储库都使用“约定”来管理自己的代码和“供应商”代码。
大多数 svn 存储库都有一个“供应商”树（与树干、分支和标签树一起）。这是所有 3rd 方供应商代码的顶部。在该目录中，您使用的每个库都有目录。例如：
branches/
tags/
trunk/
vendor/somelib
vendor/anotherlib
在每个库下面是每个库版本的目录和存储库中最新版本的“当前”目录。
vendor/somelib/1.0
vendor/somelib/1.1
vendor/somelib/current
然后你的项目的树应该像这样布置：
trunk/source #所有代码都在这里 trunk/libs #所有供应商代码都在这里
libs 目录应该是空的，但它会有svn:externals与之关联的元数据，通过：
svn propedit svn:externals trunk/libs
该属性的内容类似于（假设颠覆 1.5）：
^/vendor/somelib/current somelib
^/vendor/anotherlib/1.0 anotherlib
这意味着当您签出代码颠覆时，也会将您的供应商库签出到您的 trunk/libs 目录中。因此，当签出时，它看起来像这样：
trunk/source
trunk/libs/somelib
trunk/libs/anotherlib
这在Subversion Book中有描述（可能要好得多）。特别是关于处理供应商分支和外部的部分。