Re: Using Boost.Test header-only from CMake

From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2021-06-07 23:07:59

On 07.06.21 19:27, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> On 6/7/21 7:48 PM, John Maddock via Boost wrote:
>>> On 07/06/2021 17:26, Peter Dimov via Boost wrote:
>>>> Edward Diener wrote:
>>>>> Since it is totally legitimate to use Boost.Test in header only
>>>>> mode, and many libraries currently do this, it is hardly a "waste of
>>>>> time" to support this under CMake.
> 
>>>> Under CMake you can't use header-only libraries without linking to
>>>> their targets.
>>>> So there's no real benefit from having a separate header-only target
>>>> to link to; you can just link to the ordinary target
>>>> Boost::unit_test_framework.
>>>
>>> Doesn't that a) cause the unit test lib to be build when it doesn't
>>> need to be, and b) add the resulting binary to library link list when
>>> it doesn't need to be?
>>>
>>> But I do appreciate the simplicity of a single target ;)
>>
>> Another question is whether unnecessarily linking would cause duplicate
>> symbols or ODR issues. I believe, you're not supposed to use header-only
>> Boost.Test and then link against it, too, as the same symbols would be defined
>> both in the test and the library.
> 
> It works because the symbols in the executable override those in libraries,
> but it's indeed not quite right in principle.

Hi all,

I am skeptical about this:

* the overriding behaviour sounds to me system dependent,
* we may duplicate some of the singletons,
* some compilation information may be different between the build time
and the consumption time of the library. The 2 steps build (library
generation with one set of options, header only consumption with
potentially another set of options) may create difficult to debug
situations.

I would avoid this.

> 
>> Boost.Test could define two sets of targets - one for header-only and the other
>> for separately built library. One benefit of that is that you could use different
>> macros for these two targets, if needed (e.g. if the library sources need to
>> discriminate between the two configs).
> 
> That's probably what we'll have to do, yes.
> 
> Any input from the Boost.Test maintainer? Raffi?

I believe the correct way to do that in the CMake world is to use an
INTERFACE library, as it carries the include folder, compiler options,
defines etc together with the target cmake object, without actually
building anything, and that is what we need for header only:

https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#interface-libraries

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.

Having a 3rd target for header only sounds good to me. I can give a go
if you want.

Raffi

PS.: for those hitting the deprecated API... it's been deprecated since
almost a decade now :)