Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk