Re: [boost] Making two Boost libraries interoperate

Subject: Re: [boost] Making two Boost libraries interoperate
From: Edward Diener (eldiener_at_[hidden])
Date: 2019-04-25 01:40:22

On 4/24/2019 2:42 PM, Rene Rivera via Boost wrote:
> On Wed, Apr 24, 2019 at 1:34 PM Robert Ramey via Boost <
> boost_at_[hidden]> wrote:
> 
>> On 4/24/19 10:54 AM, Rene Rivera via Boost wrote:
>>> On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost <
>>> boost_at_[hidden]> wrote:
>>>
>>>> On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:
>>>>
>>>>>
>>>>> Not sure if this helps, but the way I did it in Boost.Flyweight is by
>>>>> isolating all serialization code
>>>>> in a separate header:
>>>>>
>>>>>
>>>>
>> https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_synopsis
>>>>
>>>> This does help! or it would help if our dependency tools understood
>>>> this.  In particular flyweight library is not dependent on the
>>>> serialization libraries.  Only apps which use the flyweight library AND
>>>> the serialization library are dependent on the serialization library.
>>>> Our notion of "dependency" obscures this.
>>>>
>>>
>>> It's only "our notion" in the sense that they mirror the notion of
>>> dependencies that users of *external* package managers, dependency
>>> managers, and users thereof have.
>>
>> Right.  I don't mean to suggest that it's only boosts problem.  It's a
>> problem in the assumptions that all these packages make. As more and
>> more projects are built by composition of more and more libraries (a
>> good thing!)  It becomes apparent that the original "naive notion"
>> breaks down. That's what we're seeing.
>>
> 
> The limit of your suggestion/desire amounts to making all source code
> globally available as individually addressable TUs. That limit is untenable
> to almost all developers. And hence the line must be drawn some place in
> between. The existing PDMs have draw it at the published logical
> boundaries. For the rather same rationale that it's easy to reason about
> for the end-users. And it's the end-users we are trying to satisfy. I.e.
> it's not a "naive notion". It's an experientially derived at end-user
> oriented method.

In theory you may be right but in practice I side with Robert Ramey. If 
I know that when using library X I will not be including a particular 
header file which creates a dependency on library A, which itself has 
dependencies on library B and C, then my practical view is that using 
library X does not depend also on libraries A, B, and C, even when some 
dependency report says that library X depends on libraries A, B, and C. 
Therefore the dependency report is not applicable in my particular case. 
With well-designed libraries my particular case will often be the case 
for many other users of libraries. Therefore while in theory you may 
defend dependency reports which take the modular approach, in practice 
that approach can easily lead to wrong conclusions.

That many even well established C/C++ packages do not design themselves 
optimally so as to minimize dependencies depending on what header files 
are included by a TU, and most, if not all, package managers do not have 
the facility for installing packages and their dependencies based on 
what "components", translated to header file inclusions and possibly 
shared libraries, is not the fault of the end user of C++ but rather our 
notion of dependencies.