On 2019-04-24 11:10 a.m., Andrzej Krzemienski via Boost wrote:
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.
That's exactly the current situation. Sorry if that wasn't clear enough from my reply.
IOW, why prefer Boost.MPI to Boost.Python for hosting this "gluing" module?
It isn't a "gluing" module: Boost.Python has no business in knowing anything about Boost.MPI. Conceptually, the Boost.MPI Python bindings belong to Boost.MPI, but are treated as an extension so as not to leak the added dependency on Boost.Python into Boost.MPI itself (thereby letting users who don't need Python bindings not accidentally depend on it). Likewise with Boost.Serialization. If for a project X you want a layer that adds serialization support, but you don't want X as a whole to depend on it, make it a X extension. Stefan -- ...ich hab' noch einen Koffer in Berlin...