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

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-18 01:39:40

Le 18/10/13 00:24, Stephen Kelly a écrit :
> Hi there,
>
> my plan for modularizing and modernizing Boost was roughly this:
>
> * Phase 0 - remove dead weight by bumping compiler feature requirements
> * Phase 1 - move some files around so that the modularized repos form a
> mostly directed graph
> * Phase 2 - Form some kind of 'boost core library' or 'boost feature
> normalization library' from the guts of existing libraries like
> type_traits, static_assert, config mpl and utilities.
> * Phase 3 - Try to port the mpl to variadic templates so that the
> dependency on Boost.PP is not needed when variadic templates are available.
>
> I recommend completing up to phase 2 before migrating to git, as
> otherwise files will have to be deleted from one repo, and added to
> another without history.
>
> Phase 0 is aborted, so let's look at phase 1.
>
> [Note: This should go without saying, but my experience on this list
> tells me it needs to be said:
>
> * I do not propose making many commits with the commit message 'migrate'
> * The below is scripted for your understanding only. Scripting gives an
> exactness which prose does not, and allows reproducibility. Don't take
> it too literally.
> * Of course, forwarding headers should be understood to be left behind
> when a file is moved, where possible.
> * Don't cry too loudly about where I'm moving files to. See Phase 2
> above, and understand that this is partly only an experiment to see how
> modularization can be done.
>
> EndNote]
>
> The remaining problematic edges are:
>
>   conversion->range
>   conversion->math
>   range->algorithm
>   math->multiprecision
>   concept_check->parameter
>
> Assuming they can be broken by moving some files aroung (I believe they
> can be), we end up with a small graph of strongly connected components:
>
>   http://steveire.com/boost/graph_after_remaining.dot
>   http://steveire.com/boost/graph_after_remaining.png
>
> There are now 18 edges and 11 nodes.
>
> Looking at the entire graph again, we get this:
>
>   http://steveire.com/boost/graph_final.dot
>   http://steveire.com/boost/graph_final_small.png
>
> Obviously, this is not perfect, but it is a beginning, and it is mostly
> now a directed graph.
>
>
Thanks for working on this.

The dependency between thread and interprocess can be broken if we 
extract unique_ptr from interprocess and move it to smart_ptr.

The dependency of thread to chrono/date_time could be broken after the 
work started by Andrey in the sync directory. But I suspect that this 
will not be ready for the next release.

The new parts will be
* sync: contains basic synchronization tools, as mutexes, 
condition_variables, locks,
* system_chrono : contains something similar to Boost::Chrono but 
restricted to nanoseconds (less meta-programming needed)

The new dependencies will be

* chrono -> system_chrono
* date_time -> system_chrono
* sync -> system_chrono
* thread -> system_chrono

and later on
* thread -> sync ?

Note system_chrono doesn't exists yet (it is included in sync) and could 
also be moved to detail.

Do someone know which parts of Boost.Thread are used by Boost.Spirit and 
Boost.Pool? Knowing this would help us to see if these libraries could 
depend on the new sync repository.

BTW, I don't see Boost.Atomic in the picture.

Best,
Vicente