Re: [boost] is review system in place is extremely slow? (was Re:[rfc] rcpp)

Subject: Re: [boost] is review system in place is extremely slow? (was Re:[rfc] rcpp)
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-02-24 18:55:27

On Wed, Feb 24, 2010 at 11:08 AM, joel falcou <joel.falcou_at_[hidden]> wrote:

> Robert Ramey wrote:
>
>> Vladimir Prus wrote:
>>
>>
>>
>>> I'm the review manager of Boost.Task but the library is not ready
>>>> for review, because now Boost.Task depends on Boost.Move,
>>>> Boost.Fiber and Boost.Atomic (which is not yet on the review queue).
>>>> Maybe the review withards could add this on the schedule page.
>>>>
>>>>
>>> It's perfectly OK to move those 3 libraries to the 'detail' namespace
>>> of Boost.Task and have review as it is, as opposed to waiting. What
>>> do you think?
>>>
>>>
>>
>> I think I caught hell for doing something similar in the serialization
>> library.  I had to make a number of components such as
>> BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc.
>> which I put into boost  - (not detail) and year afterwards this
>> was raised as a huge problem.  And this was even though the
>> components had been their through two reviews.  So I would
>> be careful about doing this.
>>
>>
> This really seems to make the "have a layered boost" proposal sensible.
> We should definetively separate core boost tools and utility library from
> system wide
> scale libraries.
>
>
I have to agree with this.  It is both annoying and unnecessary that if all
I want is one simple library, I have to have almost every other library on
my system.

Things like mpl, regex,  preprocessor, variant, unordered, etc should
certainly be at a completely different layer than extremely high level
libraries like GIL, wave, etc.

How to define these layers is of course the question.

Perhaps a first step would be to carefully draw up a chart of the current
dependency graph between the entire set of libraries, and see what can be
extracted from there.