Re: [boost] [modularization] Modularizing Boost (modularization)

On 10/18/2013 12:24 AM, Stephen Kelly wrote:

If the dependencies between repositories are analysed, the result is this graph:

http://steveire.com/boost/graph_all.dot http://steveire.com/boost/graph_all_small.png

Hello, I've analyzed the dependency graph of boost to see the result of the changes made since my last report. I want to make a special appeal. [ Please: * Note my use of the word 'recommend' * Note that my email does not constitute acceptance of any plan. * Note that general objections to modularization have already been raised recorded and don't need to be raised again. * Note that some modularization is happening, even if you don't want it to Please: * If you are confused by something in my mail * If you have a musing about something which you could investigate yourself but don't want to * If you think my mail contains a factual error, then please: ** Investigate thoroughly ** Search recursively Then consider mailing me off-list to resolve the confusion, not on-list. Let's keep the mailing list thread on-topic and high-quality. plz k thx. EndAppeal] The diff of total edges compared to my previous report is here: http://www.steveire.com/boost/nov1_all.diff The edges directed at detail which have been removed relate to Daniels change in Boost2Git. The coroutine library had some deprecated code removed, which removed two edges (And incidentally is yet more evidence, if more was needed, adding to what I have said before: http://thread.gmane.org/gmane.comp.lib.boost.devel/243094/focus=243269 ) The 'new' flyweight dependency on smart_ptr was actually already pre-existing, but my script missed it before. Similar is true for the function and multi_index dependencies on smart_ptr: flyweight/refcounted.hpp:#include flyweight/detail/recursive_lw_mutex.hpp:#include function/function_base.hpp:#include multi_index/detail/safe_mode.hpp:#include Including detail headers from another library is a code-smell. Something is might be wrong. The dependency from property_map to graph is removed, but it has gained dependencies on integer and mpi. We'll come back to that later. Erics change removed 'proto -> spirit' The thread library gained a new dependency on intrusive. This relates to a patch 4 days ago which added thread/csbl/memory/pointer_traits.hpp:#include The thread library uses intrusive_ptr already, but that comes from the smart_ptr library. I recommend moving pointer_traits.hpp from intrusive to type_traits. I generally repeat my recommendation to move other traits to type_traits too. So, commits since my last report result in both adding and removing edges. The current diff of the strongly connected graph is here: http://steveire.com/boost/nov1_strong.diff http://steveire.com/boost/nov1_strong.dot 633 edges were removed and 4 were added: + function -> smart_ptr + multi_index -> smart_ptr + property_map -> mpi + thread -> intrusive So, the smart_ptr detail files and traits files actually matter. The diff of nodes is here: - config - integer - io + mpi - static_assert Despite the efforts of Edward and Jeremiah both graph and property_map are still in the graph of strongly connected nodes. The reason is that the parallel subdirectory of property_map now depends on mpi, as of https://svn.boost.org/trac/boost/changeset/86381 I recommend removing the includes as recommended by Edward, and creating a separate library/repo for the parallel property_map: http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245280 Doing so results in this graph: http://steveire.com/boost/nov1_strong_with_property_map_parallel.dot Which corresponds to this diff of nodes, compared to my previous report: - any - bimap - config - graph_ - integer - io - lambda - multi_index - property_map - property_tree - static_assert - test - timer - tti - xpressive If we again, for the sake of simplifying the core, treat (type_traits|mpl|detail|utility|smart_ptr|typeof) as a single node, the remainder of the strong graph is this: http://steveire.com/boost/nov1_strong_with_property_map_parallel_and_corelib... http://steveire.com/boost/nov1_strong_with_property_map_parallel_and_corelib... There are obviously other worthwhile changes which could reduce this further, some of which I recommended in my last report. I'm still at a loss to reason with pushing forward with git migration instead of making these changes which have demonstrated edge removal, are valuable and are are easy cheap and quick. Thanks, Steve.