|
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