Boost logo

Boost :

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

On 10.06.21 23:36, Andrey Semashev via Boost wrote:
> On 6/9/21 2:05 PM, Rainer Deyke via Boost wrote:
>> On 08.06.21 09:33, Gavin Lambert via Boost wrote:
>>> 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.
> CMake defines targets for header-only libraries, which can have
> dependencies on other targets, including on static or shared libraries.
> So the program that "links" to the header-only library picks up its
> dependencies recursively. As a result, the linker is invoked with all
> (binary) libraries in the dependency tree.

If this functionality works the way I think does, then I think it should
not be used.

> Whether you can consider such library header-only in the first place is
> a philosophical question. I do, because otherwise any library that calls
> the standard library cannot be called header-only.

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.

Again, to make my point absolutely clear: header-only library B "using"
library A does not imply a dependency from B to A. Instead, it implies
a requirement on a program P that uses B to also link to A. Header-only
libraries use interfaces. Programs link to implementations.

Rainer Deyke (rainerd_at_[hidden])

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