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 :
> I have uploaded dependency diagrams for all boost libraries here:
> 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
> edges are removed, they cease to exist as incidental modules, and the
> dependency graphs simplify:
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
which break the cycle also.
> 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.
Agreed, removing the circular dependencies between these modules seems
I would however apply the suggestion to break the 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.
> 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
See the suggestion for
> The "incidental scope_exit" module is being addressed afaiu, but it is also
> not a problem, transitively speaking. Nothing depends on either of them.
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.