c++ - 为什么很多项目不提供预编译的二进制文件？

Question

这个问题对我来说已经很久了。我不经常使用 c++，而且似乎大多数 cpp 库都以 zip 文件或包含源代码的 tar 球的形式提供。

所以，问题是：

为什么这些项目不提供预编译的二进制文件？

我目前对 " autoconf, make, make install, ..." 过程的理解是确保一切正确，然后将源代码编译为可执行文件或一些库。但如果我们最终得到相同的东西，为什么我们每次都要编译它呢？我并不是说要为编译好的库维护一个单独的项目，但是在调试和测试过程中，这些文件应该是自动生成的，为什么不把它们放到发布文件中呢？

比如：FTGL库的源码自带Visual Studio解决方案文件（.sln），如果他们用这个来开发和调试，为什么不把编译好的二进制文件放到他们的发布文件中呢？

标签： c++libraries

Answer 1

平台通常有一个通用的 C ABI，它规定了符号命名、函数调用约定和其他低级细节。以 ABI 为目标的编译器可以与其他执行相同操作的编译器互操作。Linux 库和 Windows 库不兼容，但通常可以为每个目标平台构建少量版本：一个用于 Linux，一个用于 Windows，等等。

C++ 库没有这样的标准。名称修饰因编译器而异。编译后的 C++ 库通常只能由相同版本的相同编译器使用。由同一编译器的不同版本编译的库甚至不一定兼容。要预先构建一个库，您必须使用数十个版本的 g++、数十个版本的 clang 等构建......这是不切实际的。

分发 C++ 库很困难。一些常见的策略是：

1. 仅使库标头成为最终用户，因此最终用户只是#include库标头。无需编译。

2. 分发头文件和源文件，并要求最终用户构建库。

3. 用 C 实现库并在头文件中提供 C++ 包装器。该库可供 C 和 C++ 程序使用。如果需要，可以预先构建 C 部分。

4. 与上一个项目符号相反，在 C++ 中实现库并添加 C 包装器。包装器将定义一组extern "C"调用 C++ 代码的独立函数。

例如，Boost 混合使用了策略 1 和 2。如果您只使用 Boost 中只有标头的部分，那么您所要做的就是#include在程序中使用它们的标头，超级简单。如果您使用非仅标题部分，例如线程或正则表达式组件，那么您必须编译它们，这需要一段时间。

3 和 4 对于您不想分发代码的专有库很有用。