śr., 24 kwi 2019 o 15:03 stefan via Boost
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;