Boost logo

Boost :

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2013-10-21 13:29:08


On Sat, 19 Oct 2013, Edward Diener wrote:

> On 10/19/2013 4:39 PM, Jeremiah Willcock wrote:
>> On Sat, 19 Oct 2013, Edward Diener wrote:
>>
>>>> I had thought going the other way would be better: the files in
>>>> Boost.Graph that property map code depends on don't themselves use much
>>>> other graph code. Thus, they can be moved to Boost.PropertyMap without
>>>> too much work, and that keeps all of the property map types that are
>>>> there now in that library. There are other property map types
>>>> (sequential and parallel) in Boost.Graph that should likely also be
>>>> moved even though they don't need to be for dependency reasons.
>>>
>>> If you do that it looks like you are then keeping a dependency for
>>> property_map on multi_index, serialization, and optional. I am not
>>> saying this is wrong if you feel that a distributed_property_map
>>> really should be part of property_map, since those addititional
>>> libraries are very useful for Boost libraries. I just wanted to point
>>> that out. Whereas the more normal non-distributed property map does
>>> not need to use those libraries AFAICS.
>>>
>>> Another option is to have distributed_property_map be a separate
>>> libray of its own. More work, obviously, but this would create a more
>>> minimal set of dependencies for property_map itself.
>>
>> A separate library might make more sense, actually. Another option
>> would be for property_map/parallel to be treated as a separate library
>> without being moved in the Boost tree.
>
> I think that would be fine actaully.
>
> For that to work you will need to move the specializations of
> distributed_property_map from their places in property_map.hpp and
> vector_property_map.hpp to the property_map parallel directory as separate
> files with theier own names, as well as remove the header file inclusions for
> the parallel subdirectory in the otiginal files. I think that would satisfy
> the end-user who wanted to use property_map without having to drag in those
> dependencies for distributed_property_map.
>
> Also the distributed_property_map should probably then be documented as part
> of property_map rather than as part of graph, although graph could have the
> appropriate link to that documentation.
>
> Similarly tests for distrubuted_property_map should be part of that
> implementation rather than graph, and the correct header files referenced.

Right now, there is a #include from <boost/property_map/property_map.hpp>
to a couple of files in the <boost/property_map/parallel/> directory,
conditioned on a macro being defined. Now that the parallel subdirectory
will be treated as a separate library, this is likely to count as a
dependency (which will be circular). Should I keep that in for
compatibility?

-- Jeremiah Willcock


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk