Re: [boost] [modularization] Modularizing Boost (modularization)

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-10-19 17:50:47

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.

>
>>>> My goal is purely to have property_map be not dependent on graph since
>>>> it is its own concept. I have a use for property_map totally outside
>>>> of any use for graph in a library I am still developing, thus my own
>>>> willingness to do this work.
>>>
>>> I agree with your goal, but I think it makes more sense for
>>> distributed_property_map to be in PropertyMap rather than Graph (with
>>> its dependencies moved there as well).
>>
>> If you feel that is the way it should be please go ahead and implement
>> that change. My goal was to make property_map not dependent on graph.
>
> That is what my proposed changes would accomplish as well, but they do
> not fix the multi_index, etc. dependencies you mention above.