Re: [boost] Making two Boost libraries interoperate

Subject: Re: [boost] Making two Boost libraries interoperate
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-04-25 23:12:40

On Thu, 25 Apr 2019 at 03:40, Edward Diener via Boost
<boost_at_[hidden]> wrote:
> 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.

e.g. when using just
#include <boost/mp11.hpp>
or together with
#include <boost/mp11/mpl.hpp>
then MP11 does not or does depend on MPL.

I side with Robert then too.

I think this (and the flyweight above) opt-in approach is something
worth to consider and strive to refactor libraries accordingly.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net