Re: [boost] [Modularization] Dependency diagrams

Subject: Re: [boost] [Modularization] Dependency diagrams
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-15 09:11:27

Le 14/06/14 20:43, Stephen Kelly a écrit :
> Hello,
>
> I have uploaded dependency diagrams for all boost libraries here:
>
>   http://www.steveire.com/boost/deps-june-14/
>
> The following incidental modules exist:
>
>   incidentalModules["mpl"] = ("mpl", "type_traits", "typeof", "utility")
>   incidentalModules["math"] = ("math", "lexical_cast")
>   incidentalModules["spirit"] = ("spirit", "pool", "thread",
>                                 "date_time", "serialization",
>                                 "chrono", "interprocess")
>   incidentalModules["graph"] = ("graph_", "disjoint_sets", "bimap",
>                                 "property_map", "mpi", "graph_parallel")
>   incidentalModules["scope_exit"] = ("scope_exit", "local_function")
>   incidentalModules["range"] = ("range", "algorithm", "tr1", "random")
>
> The "incidental spirit" module and the "incidental range" modules are
> problematic. When the
>
>   serialization->spirit
>   range->algorithm
>
> edges are removed, they cease to exist as incidental modules, and the
> dependency graphs simplify:
>
>   http://www.steveire.com/boost/after-edge-removal-june-14/
>
> Compare:
>
>   http://www.steveire.com/boost/deps-june-14/assign.png
>   http://www.steveire.com/boost/after-edge-removal-june-14/assign.png
>
>   http://www.steveire.com/boost/deps-june-14/range.png
>   http://www.steveire.com/boost/after-edge-removal-june-14/range.png
>
Stephen, I really appreciate the diagrams you are providing and the 
introduction of the incidental module.
> There are obviously more edges that can be investigated, but I recommend
> addressing
>
>   serialization->spirit
See 
https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#DateTime-Serialization 
which break the cycle also.
>   range->algorithm
See https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#Range-Algorithm
> as a priority for now to remove those incidental modules.
>
>
> The "incidental mpl" module is not a priority problem, because anything
> which depends on the "incidental mpl" module mostly also depends on its
> dependencies. So, transitively speaking, it is mostly not a problem. It
> would be nice to resolve it a bit, but it does not need to be a priority.
>
>   http://www.steveire.com/boost/deps-june-14/mpl.png
>
Agreed, removing the circular dependencies between these modules seems 
quite complex.
I would however apply the suggestion to break the TypeTraits->TypeOf 
dependency 
https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#TypeTraits-Typeof.
> The "incidental graph" module is not a priority problem because few other
> modules depend on any of it (only numeric_odeint). So, transitively
> speaking, it is mostly not a problem.
Agreed.
> It would still be nice to resolve it a
> bit to affect the modules inside the closure, but it does not need to be a
> priority.
>
>   http://www.steveire.com/boost/graph-rdeps-june-14.png
See the suggestion for
https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#Bimap-PropertyMap
https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#PropertyMap-MPI
https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#Grapth-DisjoinSet-Grapth
https://svn.boost.org/trac/boost/wiki/ModuleDepednecies#Grapth-GraphParallel
>
> The "incidental scope_exit" module is being addressed afaiu, but it is also
> not a problem, transitively speaking. Nothing depends on either of them.
Agreed.

If you have other suggestions, please add them.
It would be great if we can transform the suggestions on decision and 
know who can take care of the task.

Thanks,
Vicente