On 3 February 2015 at 10:49, Peter Dimov
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