This question has been for quite a long time for me. I don't use c++ very often, and it seems most cpp libraries are provided as a zip file or tar ball containing source code.
So, the question is:
Why those projects don't provide a pre-compiled binary file?
My current understanding of the "autoconf, make, make install, ..." procedure is to make sure everything is correct and then compile source codes to a executable file or some libraries. But if we are eventually getting the same thing, why should we compile it every time? I didn't mean to maintain a separate project for compiled libs, but during debug and test process, those files should be generated automatically, why don't just put them into the release file?
For example: the FTGL library's source comes with visual studio solution files (.sln), if they uses this to develop and debug, why don't they put the compiled binary into their release file?
Platforms generally have a common C ABI that dictate symbol naming, function calling conventions, and other low-level details. Compilers that target that ABI can interoperate with other compilers that do the same. Linux libraries and Windows libraries are incompatible, but it is usually possible to build a small handful of versions for each targeted platform: one for Linux, one for Windows, etc.
There's no such standard for C++ libraries. Name mangling varies from compiler to compiler. Compiled C++ libraries can typically only be used by the same compiler at the same version. Libraries compiled by different versions of the same compiler aren't even necessarily compatible. To pre-build a library you'd have to build with dozens of versions of g++, dozens of versions of clang, etc... It's not practical.
Distributing C++ libraries is difficult. Some common strategies are:
Make the library header-only so end users just #include library headers. No compilation required.
Distribute header and source files and require the end user to build the library.
Implement the library in C and provide C++ wrappers in header files. The library can be used by both C and C++ programs. The C portion can be pre-built if so desired.
Inverse of the previous bullet, implement the library in C++ and add C wrappers. The wrappers would define a bunch of freestanding extern "C" functions that call into the C++ code.
Boost, for example, uses a mix of strategies 1 and 2. If you only use the parts of Boost that are header-only then all you have to do is #include their headers in your program, super easy. If you use non-header-only pieces such as the threading or regex components then you have to compile them, which takes a while.
3 and 4 are useful for proprietary libraries where you don't want to distribute the code.