On 10/18/2013 07:39 AM, Vicente J. Botet Escriba wrote:
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.
Thanks for the appreciation.
The dependency between thread and interprocess can be broken if we extract unique_ptr from interprocess and move it to smart_ptr.
unique_ptr.hpp includes several other interprocess lib headers. Those would have to be either moved or resolved too.
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)
Would these be two new git repos/packages?
The new dependencies will be
* chrono -> system_chrono * date_time -> system_chrono * sync -> system_chrono * thread -> system_chrono
And what will system_chrono depend on?
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.
Why don't you check things like this yourself, instead of asking on a mailing list and introducing a human round trip? This isn't the first time you've asked things like this. I'm really curious why you try to introduce a human round trip rather than run a simple 'git grep' or whatever equivalent tools that you presumably have at your disposal.
BTW, I don't see Boost.Atomic in the picture.
What picture? Boost.Atomic appears in the graph_all.dot. Thanks, Steve.