Re: Header-only libraries linking to compiled libraries...

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-11-02 21:58:19

On 11/2/21 21:26, Peter Dimov via Boost wrote:
> ... 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.

Is it possible to use CMakeLists.txt, if one is present for a library? I
believe, we have those even for header-only libraries.

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

As I said in the Boost.UUID bug, I'm opposed to dummy compiled libraries
where there shouldn't be one in the first place. Header-only libraries
need to stay header-only, as in some cases this makes a difference
between a library being used or not.

As I also suggested in the bug, the problem needs to be solved in CMake
and headers. Two immediate workarounds (besides reusing CMakeLists.txt,
if possible) I see are:

- Stop defining BOOST_ALL_NO_LIB in CMake config.
- Ignore BOOST_ALL_NO_LIB (and library-specific equivalents) for linking
non-Boost libraries.

Either of those would allow auto-linking to hide the problem.

The right solution would be to find a way to generate CMake targets for
header-only libraries while still maintaining them header-only.