On Fri, Oct 31, 2008 at 12:07 PM, Michael Jackson <[EMAIL PROTECTED]> wrote: > > 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.
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 _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
