On 02/11/2021 18: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.
[snip]
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.
The convention in cmake world is that INTERFACE libraries declare what dependencies they have in their INTERFACE_LINK_LIBRARIES export, and when someone tries to link against that INTERFACE library and they don't supply the dependencies, cmake fails the configure. If the end user wants to inject dummy targets to please cmake, that's for the cmake end user to decide, not Boost. Other end users may declare a library target alias to cmake to have those dependencies alias other libraries the end user has set up. All that is on the end cmake user to handle. Nothing to do with Boost. All Boost has to do to be a good actor is prefix its INTERFACE libraries with Boost:: namespacing in the dependencies list, and call it a day. Niall