|
|
Boost Interest : |
Subject: Re: [Boost-cmake] CMake modularization update
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-10-30 23:14:16
On Thu, Oct 30, 2008 at 2:26 PM, Michael Jackson
<mike.jackson_at_[hidden]> wrote:
>
>
> On Oct 30, 2008, at 2:17 PM, David Abrahams wrote:
>
>>
>> on Wed Oct 29 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote:
>>
>>>> I added some debugging into the BoostCore.cmake modularization code so
>>>> that
>>>> I can try and figure out what has been and has NOT been modularized.
>>>> What I
>>>> am coming up with is 27 libraries have been modularized and there are 79
>>>> libraries. So that leaves 52 libraries to be modularized. Is that
>>>> Correct?
>>>
>>> That sounds right. I suggest modularizing from the leaves, and
>>> avoiding trying to modularize those libraries that are tangled in the
>>> core of Boost-config, type_traits, MPL, preprocessor, etc.
>>
>> Doug, what's your opinion of where that should go in the long run?
>> Should we leave it alone, or should we eventually break these things
>> down into modularizable pieces?
>>
>> --
>> Dave Abrahams
>> BoostPro Computing
>> http://www.boostpro.com
>
> I have all but 2 of the "libraries" from the "libs" directory modularized.
> The unfinished libs are:
> compose: Nothing that I can find header-wise needs to be modularized
> mem_fn: Seems like just a single header that needs to be modularized.
Cool. Compose is basically a dead library, which I deprecated and---I
thought---removed a long time ago.
> 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.
> I do have a limited subset of boost trunk building with CMake at this point
> in time.
> Who ever put the graphviz file generation in place.. THANK YOU.. it saved me
> a lot of time trying to run down dependencies that were or were not needed.
> I can send an image of the latest dependency graph as I have things now if
> wanted.
That would be helpful. I hacked up the GraphViz generation for exactly
that reason: visualizing the dependencies makes it a lot easier to
detangle what's really going on!
- Doug