这个问题对我来说已经有很长一段时间了。我不经常使用 c++，似乎大多数 cpp 库都是以包含源代码的 zip 文件或 tar 球的形式提供的。
所以，问题是：
为什么这些项目不提供预编译的二进制文件？
我目前对"autoconf、make、make install、......"的理解。过程是确保一切正确，然后将源代码编译为可执行文件或某些库。但是，如果我们最终得到同样的东西，为什么我们每次都要编译它呢？我并不是要为编译的库维护一个单独的项目，但是在调试和测试过程中，这些文件应该自动生成，为什么不将它们放入发布文件中呢？
例如：FTGL 库的源代码附带 Visual Studio 解决方案文件 (.sln(，如果他们使用它来开发和调试，为什么不将编译的二进制文件放入他们的发布文件中？
平台通常有一个通用的 C ABI，用于指示符号命名、函数调用约定和其他低级细节。面向 ABI 的编译器可以与执行相同操作的其他编译器进行互操作。Linux 库和 Windows 库是不兼容的，但通常可以为每个目标平台构建少量版本：一个用于 Linux，一个用于 Windows，等等。
C++图书馆没有这样的标准。名称重整因编译器而异。编译C++库通常只能由同一版本的同一编译器使用。由同一编译器的不同版本编译的库甚至不一定兼容。要预先构建一个库，你必须使用几十个版本的 g++、几十个版本的 clang 等来构建......这是不切实际的。
分发C++库很困难。一些常见的策略是：
-
使库标头仅，以便最终用户只需
#include库标头。无需编译。 -
分发头文件和源文件，并要求最终用户构建库。
-
用 C 实现库，并在头文件中提供C++包装器。该库可由 C 和 C++ 程序使用。如果需要，可以预先构建 C 部分。
-
与上一个项目符号相反，在 C++ 中实现库并添加 C 包装器。包装器将定义一堆调用C++代码的独立
extern "C"函数。
例如，Boost 混合使用策略 1 和 2。如果您只使用 Boost 中仅标头的部分，那么您所要做的就是在程序中#include它们的标头，非常简单。如果您使用非标头部分，例如线程或正则表达式组件，则必须编译它们，这需要一段时间。
3 和 4 对于您不想分发代码的专有库很有用。
根据您的平台，生成的二进制文件将大不相同。例如，您可以运行Linux，Mac或Windows，这些可能是64位或32位架构。
如果我将 Windows 32 位二进制文件传递给您，并且您的系统是 64 位 Mac，则二进制文件将完全不兼容。
有些项目确实为每个平台提供了一个二进制文件，或者可能是少数几个，但是拥有源代码仍然很棒，因为您可能希望修改它，只使用它的某些部分或只是理解它。