On Oct 30, 2008, at 11:14 PM, Doug Gregor wrote:
On Thu, Oct 30, 2008 at 2:26 PM, Michael Jackson
<[EMAIL PROTECTED]> 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.
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake