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