Subject: Re: [boost] Making two Boost libraries interoperate
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-24 18:43:03
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
> <boost_at_[hidden]> 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:
>>>> 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
ROFL - Ramey's Orginal Federation of Libraries.
> - Jim
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk