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.