Re: Boost.Charconv review runs January 15th - 25th, 2024

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-01-25 13:13:52

>
> 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.