Re: Using Boost.Test header-only from CMake

From: Edward Diener (eldiener_at_[hidden])
Date: 2021-06-08 13:54:49

On 6/8/2021 3:33 AM, Raffi Enficiaud via Boost wrote:
> On 08.06.21 01:58, 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
> 
> Thanks, it looks good to me and if it works for Edward, then all good :)

Again I do not know CMake, and I am totally appreciative of the work 
Peter has done to bring CMake to Boost, but I was simply arguing that if 
Boost's implementation of CMake can not deal with the header-only 
variation of Boost.Test then conceptually this appears to be a failure. 
However if whatever Peter has done allows other code using CMake to 
treat Boost.Test as header-only, as well as compiled as either a static 
or shared library when chosen, I think that is optimal.

I know that in a project on which I am working I use Boost.Test in 
header-only mode and it works fine when using b2 to run tests for the 
project. I would like to think that if I try to use CMake to run tests 
for the project using the header-only variant of Boost.Test it will 
continue to work fine. That's all really.