Re: Using Boost.Test header-only from CMake

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

On 14.06.21 01:43, Gavin Lambert via Boost wrote:
> On 11/06/2021 9:17 pm, Rainer Deyke wrote:
>> Actually, the standard library is a great example of what I am talking 
>> about.  A header-only library (B) should not care about the specific 
>> implementation of the standard library (A) being used by the program 
>> (P).  There is no link dependency from B to A.  There is a requirement 
>> from B to P that P must provide /a/ implementation of the C++ standard 
>> library, but B doesn't care if it is libstdc++ or libc++ or even a 
>> custom standard library implementation that is part of P and not a 
>> separate library at all.
> 
> It does, however, need to be sure that it is using the same standard 
> library as P (and with the same settings).  Mixing multiple standard 
> libraries into the same P will only end poorly -- which is usually also 
> true (but less immediately obvious) when mixing multiple variants of 
> other single libraries into P.
> 
> You're assuming that by not specifying an explicit link from B to the 
> standard library that it will inherently have the same settings as P. 
> You're even mostly correct, because the standard library has a bit of 
> special handling in the build tools.

No, I'm saying that by not having a separate compilation step, there is 
literally no way for B to have different settings than P, because there 
is nothing that could be compiled with different settings.  This is true 
regardless of the build system, because it is true at the compile level. 
  There is no set of arguments that the build system can pass to the 
compiler that would cause B to be built with different settings than P.

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.

-- 
Rainer Deyke (rainerd_at_[hidden])