|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-07-14 07:39:17
on Sun Jul 13 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote:
> On Sun, Jul 13, 2008 at 3:29 PM, David Abrahams <dave_at_[hidden]> 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