On Oct 31, 2008, at 2:16 PM, Doug Gregor wrote:
What I am not sure of is what to do with the remaining headers in
the
"boost" directory. Are those going to be the "core" of Boost or ?
Yeah, that's how I would do it.
So are talking about modularizing what is left into "libs/core"
then? I just
want to be really clear and certain before I make that move.
Sorry, I was very unclear. I would like the remaining libs (mpl,
type_traits, config, and whatever else is in that tangle)
unmodularized for now. There *are* circular dependencies at the
library level and they aren't trivial to untangle. It's better for the
CMake effort to leave those in the non-modularized core and let the
library authors sort out the dependencies later.
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
The latest dependency graph can be found at:
http://www.bluequartz.net/dependencies.pdf
I have also create another graph with the proposed changes above:
http://www.bluequartz.net/dependencies-core.pdf
On the "core" graph circular dependencies are labeled with colors (red
or green), compiled libraries are a brownish color and trapezoidal in
shape. The "Core" libraries are a greenish-blue and are list at the
top of the graph.
Comments on any of the above is most welcome.
_______________________________________________________
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
