On Tue, Feb 3, 2015 at 4:49 AM, 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.
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