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

Question

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

所以，问题是:

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

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

例如:FTGL 库的源代码带有 visual studio 解决方案文件 (.sln)，如果他们使用它来开发和调试，为什么不将编译后的二进制文件放入他们的发布文件中？

Answer 1

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

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

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

1. 将库 header 设为仅供最终用户使用 #include 库 header 。无需编译。

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

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

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

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

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