跨平台处理二进制依赖答案

【问题标题】：Handling binary dependencies across platforms跨平台处理二进制依赖
【发布时间】：2009-07-09 06:32:15
【问题描述】：

我有一个 C++ 项目，其中有很多依赖项。该项目应该可以在 Linux 和 Windows 上运行，因此我们已将其移植到 CMake。大多数依赖项现在都直接包含在源代码树中并与项目一起构建，因此这些都没有问题。

但是，我们有一个依赖于 Fortran 代码等的二进制文件，构建起来非常复杂。对于 Linux，它也不能作为包提供，而只能作为预编译的二进制文件或完整源代码（需要安装 BLAS 库和其他几个依赖项）。对于 Windows，同样的库可以作为二进制文件使用，为 Windows 构建似乎更加复杂。

问题是，你如何处理这样的依赖关系？只需检查受支持平台的二进制文件，并要求用户设置他的构建环境（即手动指向二进制位置），或者您是否真的尝试编译它们（即使它需要安装10 个库——BLAS 库是这里最大的痛点），还是有其他推荐的方法来处理这个问题？

【问题讨论】：

标签： c++ cross-platform dependencies

【解决方案1】：

如果二进制文件独立于构建过程的其他部分，则绝对应该签入它。但是由于您不能包含二进制文件的每个版本（我的意思是每个平台和用户可能使用的编译标志），因此从源代码构建似乎是强制性的。

我做过类似的事情。我已经签入了我需要的库/二进制文件的源代码档案。然后我编写了makefile/scripts来根据特定位置（非标准操作系统位置）的目标平台/标志来构建它们，并使我的主要构建过程指向正确的位置。我这样做是为了能够处理我需要的库/二进制文件的正确版本和选项。让事情适用于不同的平台是一项艰巨的工作，但值得花时间！

哦，当然如果你使用跨平台构建工具会更容易:)

【讨论】：

【解决方案2】：

问你一个问题。用户是否需要修改这个二进制文件，或者他们只是很高兴它在那里以便可以使用/访问它？如果他们不需要修改它，请签入二进制文件。

【讨论】：

最终用户不应修改二进制文件。唯一的问题是，如果最终用户有不同的编译开关，二进制文件可能会变得不兼容，这就是为什么我想知道首先签入二进制文件是否是个好主意。
我也有同样的问题。二进制文件很容易变得不兼容，因为我想尝试不同的平台并构建配置。 ralphtheninja，您能详细说明一下吗？

【解决方案3】：

我同意，如果不经常修改它们，请检查每个平台的二进制文件。这不仅会减少构建时间，还会减少不必要的编译带来的挫败感。

【讨论】：