前几天我在虚拟机中安装了一个 Ubuntu，然后去收集我认为主要用 C++ 进行编程所需的工具和库。
不过我遇到了一个问题，将诸如 3rd 方源库之类的东西放在哪里。据我所知，很多源代码发行版都假设它们的许多依赖项已经安装在某个位置，并假设许多工具也安装在特定位置。
举一个我目前在 Windows 上所做的例子，我是否有一个目录来保存所有源代码。 C:\code。在这个目录中，我有一个所有 3rd 方库的目录，c:\code\thirdparty\libs。这样，我可以轻松地为我编写或遇到并希望编译的任何项目的所有依赖项设置相对路径。我对设置 linux 编程环境感兴趣的原因是，似乎工具和库依赖问题都得到了有效解决，例如从源代码构建 OpenSSH 变得容易。
所以我一直在寻找一个体面的约定，当我尝试在 Linux 上组织我的项目和库时可以使用它，它易于维护和使用。
【问题讨论】：
标签： c++ linux development-environment
简短的回答：不要做“本地目录中的代码堆”的事情。
长答案：不要做“本地目录中的代码堆”的事情，因为保持最新将是一场噩梦，如果您决定分发您的代码，打包它将是一场噩梦任何体面的分布。
只要有可能，坚持使用发行版中提供的库（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 系统上构建。
还可以查看pkg-config，它现在在 Linux 发行版上使用得相当多，可帮助您包含和链接到正确的库（对于支持 pkg-config 的库）。
如果您使用 subversion 来管理源代码，则大多数 subversion 存储库都使用“约定”来管理自己的代码和“供应商”代码。
大多数 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 对此进行了描述（可能要好得多）。特别是处理vendor branches和externals的部分。
【讨论】：
【讨论】：