|
Boost : |
Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2013-10-25 08:04:53
>>> This makes no sense to me, why would property_map code belong in the
>>> graph library? They seem to be solving completely different problems
>>> and my naive assumption would be that they have no dependencies on
>>> each other, though if that were the case, we probably wouldn't have
>>> a dependency graph that looks like spagetti. Anyways, perhaps you
>>> could explain this in more detail?
>>
>> I think Edward and Jeremiah have made progress on this issue, though I
>> admit I didn't follow the details closely, so I can't say more:
>>
>> http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245276
>
> Hopefully one of them can comment.
The property map library is heavily used by the graph library and they
were introduced into Boost at the same time. One change that was made to
clean up the dependency structure is to split boost/property_map/parallel
into its own component, separate from the rest of boost/property_map.
After that, the dependency structure was [some direct dependencies that
duplicate indirect ones have been omitted]:
graph_parallel (i.e., boost/graph/parallel, boost/graph/distributed)
v^ v
property_map/parallel v
v v v
mpi <<<<<<<<<<<v<<<<<<<<<<<<<<+
v v v
graph <<<<<<<<<v<<<<<<<<<<<<<<+
v v
property_map <<+
The cycle between the top two components in the diagram was due to common
functionality used for parallelism being in the parallel graph library;
these have been moved to the parallel property map library (they were not
graph-specific and did not use the rest of the parallel graph library).
Thus, that edge is now uni-directional and there is a layer structure that
matches the goals of the contained libraries.
-- Jeremiah Willcock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk