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

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2013-10-19 16:39:20

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.

>>> 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.

-- Jeremiah Willcock