I believe that Boost should lead by example here. Libraries should be header-only as a coincidence and not by design. For example Boost.Variant2 should be header-only. But Boost.MySQL does not need to be header-only. In my opinion the best way to motivate people to learn how to properly compile and link external dependencies is to create non-header-only Boost libraries that are so compelling in features, so rewarding in value, that users will accept the cost of incorporating linkable external dependencies instead of forgoing useful libraries.
I am completely with you, and I almost switched to compiled-only a couple of releases ago. There are two points that held me back. If anyone in this ML can shed some light on how they could be solved, I'd be eternally grateful. 1. Boost.Asio and the ODR rule. ======================== As you may already know, Boost.Asio is header only and has 238329282390 config macros that modify its definitions. AFAIK all usages of Boost.Asio in your executable should employ the same config macros. For instance, BOOST_ASIO_SEPARATE_COMPILATION is used to switch some declarations from inline to external linkage, so they can be built in a separate TU. BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT is used to enable some legacy behavior on executors. Unfortunately, I have real users enabling this switch because they need it to be compatible with other libraries. If I happen to build a libboost_mysql.so binary, which version of Boost.Asio should I use? It will make my library compatible only with that version. I "solved" this by providing a separate compilation mode, where you have a src.hpp, like Beast does. This provides reductions from 50% to 75% in build times, so it's not a minor thing. Making this the default via making the library compiled by default would be great. 2. OpenSSL ========= This is currently a hard dependency, because even in plaintext mode, the protocol mandates some hashing. B2 openssl package provides far less heuristics than CMake's, specially for Windows. My users would need much more effort to build than what's needed currently. Additionally, there's currently a limitation in boost_install for depending on OpenSSL. This last point is likely workaroundable on my side, since all these problems have solutions. But I won't make the effort until point 1. gets a solution (if there is any). Thanks, Ruben.