Re: Using Boost.Test header-only from CMake

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2021-06-15 04:43:54

On 15.06.21 01:32, Gavin Lambert via Boost wrote:
> On 14/06/2021 5:34 pm, Rainer Deyke wrote:
>> B is a header-only library.  To use B, the C++ preprocessor literally 
>> pastes the code from B into P.  Therefore, B /has/ no build settings. 
>> There are only the build settings from P, which are applied 
>> indiscriminately to P's own code and the code from B that P #includes.
> 
> That's actually completely false.  The preprocessor itself *is* build 
> settings -- defines can be defined differently (along with other 
> compiler options) between the two builds.

There are no two builds in my example.  There is only P.  Yes, using B 
modifies the build settings of P, but B has no build settings of its own.

By the same token, linking P to separately compiled library A also 
modifies the build settings of P, but this is separate from the build 
settings that are actually used to /build/ A.

> And yes, there may still be two builds.  There is the build of P itself 
> (which includes A) and the build of another library C that is linked 
> into P but also includes A.  Both of these can be via B or separately, 
> and both can cause different code for B to be generated if the settings 
> differ, which is an ODR violation.

That's a different situation.  If you add a separately compiled library 
C to the equation, then C does have its own build settings, which need 
to be compatible with P's build settings.  This is true whether C uses B 
or not, and whether B is header-only or not.

Or you could, if C allows it, use C as a header-only library, which 
completely solves the problem.

-- 
Rainer Deyke (rainerd_at_[hidden])