Re: Using Boost.Test header-only from CMake

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-06-08 14:56:42

On 6/8/21 2:58 AM, Peter Dimov via Boost wrote:
> Raffi Enficiaud wrote:
>> I have not looked at the recent developments for CMake in Boost. If the
>> CMakeLists.txt I developed (under build/) is still there, it contained 2
>> targets: one for static and one for shared. Those were having different and
>> explicit names.
> 
> I decided to not do this and instead use the "normal" CMake way of relying
> on BUILD_SHARED_LIBS.
> 
> It causes problems in the more complicated cases where a compiled Boost::X
> links to header-only Boost::Y which links to a compiled Boost::Z. Client code
> can choose to link explicitly to Boost::static_X, and if X used Z directly, it could
> link to Boost::static_Z, but it doesn't. And requiring all header-only libraries
> to also provide triplicate targets so that static/shared-ness can be propagated
> correctly is (I think) infeasible. So X links to Boost::Y, and Y has to choose
> whether to link to the static or shared Z, but it doesn't know how.
> 
> (b2 does this "right" by having static/shared as a build feature, and
> propagating it automatically. No need to split your targets by hand.)
> 
> Swimming upstream is sometimes justified when it results in something
> objectively better than the accepted CMake way, but I don't believe that's
> the case here, so BUILD_SHARED_LIBS will have to do. (Similarly, I tried to do
> something b2-like with the tests, but at the end reverting to the way CMake
> wants to do things proved better.)
> 
> Getting back to Boost.Test, I've duplicated the targets with an included_ prefix:
> 
> https://github.com/boostorg/test/commit/bce2d24c8b32f47f0403766fe4fee3e2e93af0a0

Not to start a bikeshedding argument, but maybe a more generic naming 
scheme would be preferable? I'm thinking something like Boost::x names 
the default config, Boost::x::header_only means header-only variant, 
Boost::x::static means static library, and so on. This makes it possible 
to add more configurations in the future, including the library-specific 
ones, if needed.