|
|
Boost Interest : |
Subject: Re: [Boost-cmake] CMake modularization update
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-10-29 19:52:51
On Tue, Oct 28, 2008 at 4:17 PM, Michael Jackson
<mike.jackson_at_[hidden]> wrote:
> Just an update on what I have been messing around with today (really just
> want to be sure I am understanding what _really_ needs to be done).
>
>
> I merged the "branches/cmake/release" into the "trunk" locally on my machine
> by just copying the "CMake" related files from the branch working directory
> to the trunk working directory.
>
> I used a combination of zip/unzip to do this. Here is the zip command:
>
> zip -r "../boost-cmake.zip" "./" -i \*.cmake Welcome.txt CMakeLists.txt
> README.txt tools/build/CMake/\* -x ./\*/.svn/\*
Yeah, that's most if it. There's a "run.py" file in libs/python/test
that's also needed to run the Python tests (otherwise, most of the
Boost.Python tests will fail, IIRC).
>
> After that I started tracking down the call sequence to get to the
> "Modularization" step. If I am understanding everything (From reading the
> archives of this email list), the goal of the modularization task is to get
> the boost trunk into a more consistent state by having the headers located
> in the libs/$LIBNAME/include/boost directory instead of Boost/*. Is that a
> fair assessment? So after this is completed and the CMake build system is
> 100% working including regression testing and reporting then the svn
> repository would be changed to reflect the "modularized" hierarchy thus
> making the "Modularization" step in the CMake build system obsolete?
Yeah. Because we can't change the repository until everything is
modularized, we encode the headers in the CMakeLists.txt files and use
the modularize step to move things into place for testing
modularization. Running "make test" after modularizing a library is a
great way to make sure everything still works (but, it takes a while).
> 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.
I'll *try* to keep up with e-mail on the list here, but as Dave said
I'm buried right now, so there will be some lag.
- Doug