Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] CMake modularization update
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2008-11-07 11:55:14


On Oct 31, 2008, at 2:16 PM, Doug Gregor wrote:

>>>>
>>>> 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.

    Any ideas on what we would like to keep "un-modularized" for now?
Looking at the dependency
graph here are my own thoughts on which libraries should probably be
kept un-modularized for now:

        mpl
        functional
        integer
        detail
        utility
        exception
        function
        preprocessor
        concept_check
        concept
        config
        type_traits
        static_assert
        iterator
        tuple
        smart_ptr

The latest dependency graph can be found at:

http://www.bluequartz.net/dependencies.pdf

I have also create another graph with the proposed changes above:

http://www.bluequartz.net/dependencies-core.pdf

On the "core" graph circular dependencies are labeled with colors (red
or green), compiled libraries are a brownish color and trapezoidal in
shape. The "Core" libraries are a greenish-blue and are list at the
top of the graph.

Comments on any of the above is most welcome.
_______________________________________________________
Mike Jackson mike.jackson_at_[hidden]
             www.bluequartz.net


Boost-cmake list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk