on Sun Jul 13 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote:
> On Sun, Jul 13, 2008 at 3:29 PM, David Abrahams <[EMAIL PROTECTED]> wrote: >> >> on Sun Jul 13 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote: >> >>> I went ahead and hacked this up; it's in the tree now. Looks like we >>> have a bit of work to do to get all of the dependencies right. When I >>> saw some failures due to the inability to find boost/config.hpp, I >>> started wondering... should we define in advance what the "core" Boost >>> libraries are, and leave them non-modularized? Boost.Config seems like >>> the most core library of them all :) >>> >>> Or, maybe it's just better to get *all* of the dependencies in there >>> now, and it'll be easier to maintain them afterward. Thoughts on these >>> two approaches? >> >> I vote for the latter. What's the advantage in doing the former? > > Perhaps I was feeling lazy. It means a lot of dependencies for the > core things---every library tends to use type_traits, config, > mpl---but that's fine. I've patched up the dependencies for a whole > lot of libraries, but it'll take me a bit longer before I have all of > Boost building from modular libraries. Thanks for going to the extra effort. > Once I get it all working, I'll send a graph of the actual > inter-library dependencies in Boost. It might be interesting! I once ran such an analysis using some special software and happily, didn't see anything too interesting/surprising :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
