Re: [boost] Making two Boost libraries interoperate

Subject: Re: [boost] Making two Boost libraries interoperate
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-24 18:56:37

On 4/24/19 11:42 AM, 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. 
Agreed
That limit is untenable
> to almost all developers. 
Agreed
And hence the line must be drawn some place in
> between. 
Agreed.

This is why I believe that there will never be a fully automated, 
correct dependency generator.  At some point, someone will have to 
specify some of the dependencies by hand using knowledge that he has 
that is not available to the tool including "hidden dependencies" as 
well as the application(s) being built.

The existing PDMs have draw it at the published logical
> boundaries. 
That's the rub.  Right now we draw it a the "library".

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.

Hmmmm - I'm not thinking of "naive" as a pejorative term. I've tried 
made the case that what is correct on a small scale breaks down at large 
scale and characterized that as "naive"

Robert Ramey