Re: [boost] Making two Boost libraries interoperate

Subject: Re: [boost] Making two Boost libraries interoperate
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-24 15:10:38

śr., 24 kwi 2019 o 15:03 stefan via Boost <boost_at_[hidden]>
napisał(a):

>
> On 2019-04-24 8:39 a.m., Andrzej Krzemienski via Boost wrote:
> > Hi Everyone,
> > Somewhat in connection with the discussion about modularizing Boost
> > libraries, we had a certain conceptual problem recently about providing a
> > customization code that allows Boost.Serialization library to serialize
> > Boost.Optional. Such customization requires some code to be written
> > (template specializations provided).
>
> It seems intuitive to put such code with Boost.Optional. While you may
> not want to make Boost.Optional as a whole be dependent on
> Boost.Serialization, it might be possible to create an "extension"
> (technically just a header in your case) that encapsulates the
> additional dependency, and which can be considered logically separate
> from the "core" of Boost.Optional.
>
> I have similar cases where certain Boost libraries wanted Python
> bindings (using Boost.Python). For example, Boost.MPI has Python
> bindings, which are however built into a separate library. So, Boost.MPI
> wouldn't depend on Boost.Python, but the Boost.MPI Python bindings lib
> would depend on both Boost.MPI and Boost.Python.
>
> Your case is similar, only that the piece that depends on both is just a
> header, rather than a full (compiled) library.
>

I understand the mechanism with a "submodule inside a module". However, I
do not understand what you do not find the situation symmetrical. After
all, an inverse solution could be suggested for your use case: provide a
Boost.Python binding for MPL lib as a submodule of Boost.MPI. This way
Boost.Python wouldn't depend on Boost.MPI, but the Boost.Python MPI
bindings lib would depend on both Boost.MPI and Boost.Python.

IOW, why prefer Boost.MPI to Boost.Python for hosting this "gluing" module?

Regards,
&rzej;