Re: [Boost-cmake] CMake modularization update

Subject: Re: [Boost-cmake] CMake modularization update
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-10-31 14:16:21

On Fri, Oct 31, 2008 at 12:07 PM, Michael Jackson
<mike.jackson_at_[hidden]> wrote:
>
> On Oct 30, 2008, at 11:14 PM, Doug Gregor wrote:
>
>> 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.
>
> There is essentially nothing is the compose folder so I need to make those
> adjustments to the cmake files.
>
>>
>>
>>> 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.

  - Doug