On Nov 10, 2008, at 11:47 AM, David Abrahams wrote:
on Fri Nov 07 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote:
On Fri, Nov 7, 2008 at 11:55 AM, Michael Jackson
<[EMAIL PROTECTED]> wrote:
Any ideas on what we would like to keep "un-modularized" for now?
Looking
at the dependency
graph here are my own thoughts on which libraries should probably
be kept
un-modularized for now:
mpl
functional
integer
detail
utility
exception
function
preprocessor
concept_check
concept
config
type_traits
static_assert
iterator
tuple
smart_ptr
Most of these look like they belong in the core. "detail" isn't a
library. I bet "function", "iterator", "tuple", and "smart_ptr" could
be pulled out and made into modular libraries, since they shouldn't
have all *that* many dependencies.
Looks right to me.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Here are the dependencies as best I can figure out for those mentioned
by Doug:
boost_module(detail DEPENDS integer)
boost_module(tuple DEPENDS static_assert)
boost_module(function DEPENDS detail preprocessor utility)
boost_module(iterator DEPENDS mpl type_traits function concept_check)
boost_module(smart_ptr DEPENDS utility)
Basically if I pull those out then we end up with circular
dependencies in the graph. I can post a new dependency graph later
today if interested.
I can go down that path an update all the CMake files but that might
be a while since I am on some other projects at the moment although I
would like to get back to the boost-cmake sooner rather than later.
FYI: Updated to latest trunk, ran "make modularize" and then built
boost. It all still builds. The testing does fail pretty quickly
though, About 15% into the tests.
_________________________________________________________
Mike Jackson [EMAIL PROTECTED]
www.bluequartz.net
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
