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: Neil Groves (neil_at_[hidden])
Date: 2015-02-03 18:15:38

On 3 February 2015 at 10:49, 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.
>
> To get a rough idea what we're trying to accomplish, look at the bold
> parts of
>
> http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-weights.html
>
> and see what tends to predominate - it's the same few libraries over and
> over. This is not a general problem.
>
>
I'm happy to solve the Boost.Range dependencies. I suspect this is far
simpler than for Boost.Serialization. I think code simply needs to move to
other libraries. For example the Range Adapter for regexp could move to
Boost.RegExp if it is reasonable for it to depend on Boost.Range.

I've publicly stated previously that code that is in Boost.Range would be
better elsewhere. The problem has been that as a maintainer the access to
other libraries has been limited.

I think there is a pattern to the libraries that hit the top of the list.
They are very generic libraries that interoperate and extend other Boost
libraries. I think we had chosen to make optional dependencies based upon
header inclusion, and this was a valid decision at the time.

I also understand that the direction of C++ modules makes it appear that it
would be prudent to solve these dependencies in another manner, so that we
are ready to adopt them rather than being forced to start the deprecation
process very later and delay the adoption of modules. We can't be sure we
are exactly correct, but the general direction for modules is clear enough
to motivate action now.

I have no resistance to assisting with this effort. I'd like to ensure my
users get proper time to adjust via the proper deprecation procedure, but
I'm open to making changes.

Please feel free to enlist my help.

Regards,
Neil Groves