Boost logo

Boost :

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])

Boost list run by bdawes at, gregod at, cpdaniel at, john at