Boost logo

Boost :

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:
>> There are now 18 edges and 11 nodes.
>> Looking at the entire graph again, we get this:
>> 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



Boost list run by bdawes at, gregod at, cpdaniel at, john at