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