在源代码树中包含预编译的库

Question

我有一个跨平台的C++项目。在这个项目中，我们使用了几个第三方，静态编译的库，这些库非常庞大且不易构建。

目前，我们的源代码树是这个样子：

| 
+-3rdparty 
| +-include (initially empty) 
| +-lib  (initially empty) 
| +-some-library 
| +-another-library 
| 
+-source 

当检查出的代码，开发者首先生成并安装“一些库”和“其他库”。安装步骤会将正确的文件放入include和lib文件夹，然后他们可以构建我们的项目。

为了更容易地构建我们的项目，我正在考虑删除“some-library”和“another-library”，而只是将include和预编译的二进制文件放入include和lib文件夹中。这样，一个新的开发者只需要检查项目，并立即建立。

我的问题是：

1. 它是一个不好的做法，这样做呢？ （即：将预编译的库包括到您的源代码树中）。

2. 什么潜在的问题/缺点可以从这个设置产生的？

3. 对于几个平台（Windows，Mac OSX和Linux），您建议考虑哪个文件夹组织？

附加说明：我们正在使用Mercurial。

Answer 1

我对此断然拒绝，以保持的二进制文件的旧版本的版本控制系统的工作。那是很久以前的事了，我认为这对目前的VCS来说不是问题，但在实现这个想法之前请先检查一下。

如果第三方库得到更新的频率，你的资料库可能会相当大。

除此之外，我已经看到了它完成，可见它的工作。

Answer 2

好，你正努力成为跨平台的，但你的源捆绑依赖带有多个问题。

• 既然你说说建筑的依赖关系，你如何打算，以确保编译后的代码可以在开发人员的机器上运行？我怀疑Windows代码将在OS X下运行，甚至可能不是Debian Linux下的Fedora Linux Rawhide。

• 如果我已经有我的系统上安装的依赖关系，我怎么能干净地禁用在安装您的版本？为什么我会关心在退房时下载它们？

• 如果您打算将此代码加入某些Linux发行版中，打包程序会对您所引入的紧密耦合产生影响，因为您的方法在共享库工作得很好的Linux世界中不太需要。

当然你的方法在很多地方都有，大大小小，但为什么要重复他们的错误呢？如果您确实需要为开发人员提供安装这些依赖关系的快捷方式，则应编写可配置的脚本，将相关性安装到某些前缀中。并添加一些标志来禁用安装特定的依赖项。