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.