在源代码树中包含预编译库
我有一个跨平台的 C++ 项目。在这个项目中，我们使用了几个第三方静态编译的库，这些库非常庞大且不易构建。
目前，我们的源代码树如下所示：
|
+-3rdparty
| +-include (initially empty)
| +-lib (initially empty)
| +-some-library
| +-another-library
|
+-source
在检查代码时，开发人员将首先构建并安装“some-library”和“another-library”。安装步骤会将正确的文件放入 include 和 lib 文件夹中，然后它们就可以构建我们的项目。
为了使构建我们的项目更容易，我正在考虑删除“some-library”和“another-library”，而只是将包含文件和预编译的二进制文件放入 include 和 lib 文件夹中。这样，新的开发人员只需检查该项目，然后立即构建它。
我的问题是：
这样做是一种不好的做法吗？ （即：将预编译库包含到源代码树中）。
此设置可能会出现哪些潜在问题/缺点？
您建议对多个平台（Windows、Mac OSX 和 Linux）采用哪种文件夹组织？
附加说明：我们正在使用 Mercurial。
I have a cross-platform C++ project. In this project, we use several third-party, statically-compiled libraries that are quite huge and not easy to build.
Currently, our source tree looks like this:
|
+-3rdparty
| +-include (initially empty)
| +-lib (initially empty)
| +-some-library
| +-another-library
|
+-source
When checking out the code, a developer would first build and install "some-library" and "another-library". The install step would put the right files into the include and lib folders, and then they can build our project.
In order to make building our project easier, I was thinking of removing "some-library" and "another-library", and instead just put the includes and the pre-compiled binaries into include and lib folders. This way, a new developper would just have to checkout the project, and build it straight away.
My questions are:
Is it a bad practice to do so? (ie: including precompiled libraries into your source tree).
What potential problems / drawbacks may arise from this setup?
What folder organization you would suggest to account for the several platforms (Windows, Mac OSX, and Linux)?
Additional note: we are using Mercurial.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我使用过的版本控制系统绝对拒绝保留旧版本的二进制文件。那是很久以前的事了，我认为这对当前的任何 VCS 来说都不是问题，但在实施这个想法之前请检查一下。
如果第三方库经常更新，您的存储库可能会变得相当大。
除此之外，我已经看到它完成了，并且看到它起作用了。
I have worked with version control systems that absolutely refused to keep old versions of binary files. That was a long time ago, and I don't think it's a problem with any current VCS, but check before going live with the idea.
If the third-party library gets updated often, your repository might get pretty big.
Aside from that, I've seen it done, and seen it work.
很好，您正在尝试跨平台，但是将依赖项与源代码捆绑在一起会带来多个问题。
既然您谈论构建依赖项，那么您计划如何确保编译后的代码可以在开发人员的计算机上运行？我怀疑 Windows 代码能否在 Os X 下运行，甚至可能无法在 Debian Linux 下运行 Fedora Linux Rawhide。
如果我的系统上已经安装了依赖项，如何彻底禁用您的版本的安装？为什么我要在结账时下载它们？
如果您打算将此代码放入某些 Linux 发行版打包程序中，您会因为引入的紧密耦合而感到烦恼，因为在共享库运行良好的 Linux 世界中不太需要您的方法。
当然，大大小小的很多地方都在效仿你的做法，但你为什么要重蹈他们的覆辙呢？如果您确实需要为开发人员提供安装这些依赖项的快捷方式，您应该编写可配置的脚本，将依赖项安装到某个前缀中。并添加一些标志以禁用安装特定依赖项。
Good that you are trying to be cross-platform, but bundling dependencies with your source comes with multiple issues.
Since you talk about building the dependencies, how do you plan to make sure that the compiled code can run on a developer's machine? I doubt the Windows code will run under Os X, maybe not even the Fedora Linux Rawhide under Debian Linux.
If I already have the dependencies installed on my system, how can I cleanly disable installation of your versions? And why would I care to download them in the check out?
If you ever plan to get this code into some Linux distribution packagers will bug you about the tight coupling you introduced since your approach is less needed in the Linux world where shared libraries work pretty well.
Of course your approach is followed in a lot of places, big and small, but why should you repeat their mistakes? If you really need to provide your developers with a shortcut to install these dependencies you should write configurable script that installs the dependencies into some prefix. And add some flags to disable installing specific dependencies.