Re: [boost] Making two Boost libraries interoperate

On 4/24/19 10:40 AM, James E. King III via Boost wrote:

On Wed, Apr 24, 2019 at 12:50 PM Robert Ramey via Boost wrote:

...

On 4/24/19 9:00 AM, stefan via Boost wrote:

...

On 2019-04-24 11:56 a.m., 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_...

So, if I want to serialize boost::flyweight's, I need to include and link with Boost.Serialization. This, I think, makes Boost.Flyweight technically not dependent on Boost.Serialization.

Right, this is *exactly* what I tried to propose as the right approach in my first reply. :-)

Right - every library should be doing this. Likely the same applies to other libraries as well.

For Peter Dimov's dependency inspection project(s) I think would be interesting to be able to express optional headers (perhaps in each project meta?), and for each of those optional headers we could call out their dependencies separately. Chances are these are already documented per project, but not otherwise expressed.

For something like cmake it would be a question as to whether their built-in library dependency logic in FindBoost.cmake was for required, or for required and optional dependencies, but that's their call.

FWIW - I don't think there is any universal, automated method of figuring out dependencies. Ultimately these have to be crafted by hand. But a good tool and provide a good starting point and perhaps work in 90%+ situations. So I would like a tool reads a collection of one or more "top" level code modules and outputs a text file of dependent headers and source files that my project needs to include. that I can then edit that can then be fed to CMake or whatever. And BTW - this would not really be a boost thing. It should work with STD and other libraries - even those which have their own (boost or otherwise) header source dependencies. Of course to make this work on would need to be able to access all the source code which might be included. The current approach avoids this - which ultimately is why it can never work. So lets call it something which denotes this - may I modestly propose: ROFL - Ramey's Orginal Federation of Libraries. Robert Ramey Robert Ramey

- Jim

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost