[boost] [Modularization] Dependency diagrams

Subject: [boost] [Modularization] Dependency diagrams
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-06-14 14:43:27

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

There are obviously more edges that can be investigated, but I recommend 
addressing 

 serialization->spirit
 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

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

The "incidental scope_exit" module is being addressed afaiu, but it is also 
not a problem, transitively speaking. Nothing depends on either of them.

Thanks,

Steve.