Boost logo

Boost :

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2021-06-09 11:05:34


On 08.06.21 09:33, Gavin Lambert via Boost wrote:
> On 8/06/2021 4:53 pm, Edward Diener wrote:
>> I do not know CMake, so maybe my comment is irrelevant, but it seems
>> natural to me that a header-only library would always choose to use
>> some other dependent library as header-only, even when that other
>> library had static or shared variants. In other words I applaud the
>> decision of Boost.Test to provide a header-only variant and can not
>> even begin to process the fact that CMake can not deal with Boost.Test
>> as a header-only library, if that is indeed the case.
>
> A problem occurs when program P uses library A as static or shared and
> then wants to use header-only library B which also uses library A.
>
> For this to work, one of the following must be true:
>   1. library B can figure out how program P chose to link to it and
> links to it the exact same way.

A header-only library cannot *link* to anything, or it is not header-only.

A header-only library B can depend on symbols being provided by the
calling program P, which can delegate the task to library A, or to
another library C which provides the same interface as A. There should
be no direct connection from B to A. Depending on the design of B, this
may involve #including a header from A before #including a header from
B, or it can involve making the headers from A available to B so that B
can #include them directly. Where these symbols and/or headers come
from is the business of P, not of B.

-- 
Rainer Deyke (rainerd_at_[hidden])

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk