Re: [boost] To split, or not to split, or something else? RE: type_traits rewrite, modularization, dependencies, etc.

Subject: Re: [boost] To split, or not to split, or something else? RE: type_traits rewrite, modularization, dependencies, etc.
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-02-04 07:26:34

On Tue, Feb 3, 2015 at 4:49 AM, Peter Dimov <lists_at_[hidden]> wrote:

> Rene Rivera wrote:
>
>  I keep reading emails about the effort to reduce dependencies, and to
>> split libraries into core/simple + whole/big..
>>
>
> We need to keep this into perspective. There's much e-mail traffic but out
> of 118 or so libraries we want to split 2.5 into core+non-core --
> serialization, range, perhaps mpl. We also want to split hash out of
> functional, and common_type out of type_traits, and maybe fpclassify/sign
> out of math in the future, but those aren't core/non-core splits. So
> standardizing core/non-core splits would not be a priority for me.
>

I guess I'm more of a stickler about structure then :-) I look at the
(small) special cases in build scripts and I cringe. I also think that if
it's a problem now, it will continue to be a problem in the future for new
libraries. So it's better to have an agreed upon structure (and
documentation) that we can point new authors to. This is al optional
anyway. It's just that I would prefer to have *one* option instead of *N*
options for each library (even if N is small).

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail