Boost logo

Boost Interest :

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-14 07:39:17

on Sun Jul 13 2008, "Doug Gregor" <> wrote:

> On Sun, Jul 13, 2008 at 3:29 PM, David Abrahams <dave_at_[hidden]> wrote:
>> on Sun Jul 13 2008, "Doug Gregor" <> 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

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at