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

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-11-01 04:21:39

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 <boost/detail/atomic_count.hpp>
  flyweight/detail/recursive_lw_mutex.hpp:#include
<boost/detail/lightweight_mutex.hpp>
  function/function_base.hpp:#include <boost/detail/sp_typeinfo.hpp>
  multi_index/detail/safe_mode.hpp:#include
<boost/detail/lightweight_mutex.hpp>

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
<boost/intrusive/pointer_traits.hpp>

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.dot
 
http://steveire.com/boost/nov1_strong_with_property_map_parallel_and_corelib.png

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.