$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-06-07 17:27:58
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.
> 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?