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

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-18 03:58:07

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.