On Jul 29, 2013, at 4:17 AM, Stephen Kelly
Hi there,
I've been working on the modularization effort from a CMake point of view, and from an 'actual modularization' point of view, looking at interdependencies:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26
I'd like to start on reducing interdependencies, and I'd like to start reasonably small, as no-one in the boost community knows me and see how it goes from there. I'm very active in CMake, Qt and KDE.
Currently, in the modularized boost repos, boost::config and boost::core depend on each other. I listed 3 ways of fixing this on the ryppl list:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201
My preference is the removal of BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS, and requiring compilers to have the feature. That way boost/config/suffix.hpp will no longer need to include boost/{non_,}type.hpp.
My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost.
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
gcc 3.3 as a minimum seems ok to me. I'm a bit less sure about cutting out VC++ 7 - but we don't seem to have any testers for it. I don't have any opinion on the version bump for Digital Mars or Icc. That macro appears to be used in Boost.Python, Boost.PropertyMap, Boost.CRC, Boost.Math and Boost.MPL, and maybe other libraries. I assume you're volunteering to update them as well (and the Boost.config docs and tests, etc)? -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki