Header-only libraries linking to compiled libraries...

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-11-02 18:26:44

... create problems (at least) for CMake users, because a project
using a header-only library must link to its compiled dependencies
by hand.

(Important Note: this is not about the CMake build of Boost. It's
about the b2 build of Boost, and the CMake configuration files
it generates.)

Compiled libraries don't have this problem, because they have
CMake targets, and linking to the library target automatically links
to the dependencies. For instance, linking to Boost::filesystem
would automatically link to Boost::atomic (and on Windows, to
bcrypt.lib) as needed.

However, as pointed out in https://github.com/boostorg/boost_install/issues/54,
header-only libraries such as Process or UUID have no CMake targets.
Consequently, it's not possible for the CMake project to link to
Boost::uuid and automatically inherit the dependency to bcrypt.lib,
or to link to Boost::process and automatically acquire a dependency
to Boost::filesystem.

Since the CMake configuration files that are generated by `b2 install`
define CMake targets based on the b2 targets, it's not possible to fix
this just on the boost-install side. If we want Boost::process to appear
as a target in CMake, we need boost_process to appear as a target in
b2, that is, we need libs/process/build/Jamfile to exist.

The easiest way to fix it - if we decide to do something about it - is to
create dummy compiled libraries for each such header-only library
that isn't really header-only because of dependencies. A number of
Boost libraries are already header-only with a stub library for backward
compatibility (System, DateTime, Regex), so this wouldn't be something
novel.