CMake Modularization Status

All Boost libraries currently inhabit a ​single subversion repository. This page documents the status of the effort to modularize boost. Those working on the modularization are simultaneously porting the build/test system from ​Boost.Build to ​CMake.

Automated Tests

You can review the current status of modularization ​here.

Modularization

Each time there's a new commit to Boost's trunk, ​this script modularizes a ​Git repository mirroring Boost SVN and distributes the updated files into separate ​per-library git repositories. As ​you can see, the script is being kept up-to-date by Daniel Pfeifer.

The column labelled “Boost.Modularize” on the right side of the ​automated test page shows the modularization process itself. If that column is green, it tells you that every file is currently “accounted for” and has been assigned to a module. If there are files that don't have a modularized home, we get an error like ​this one. (in that run, it looks like someone just added the Boost.Heap library). When that happens, Daniel get an email and he fixes it.

To prepare to run modularization on a local machine:

# get the the modularized boost superproject
git clone http://github.com/boost-libs/boost modules

# Update all the submodules
cd modules
git submodule update --init                     # takes a couple of minutes
cd ..

# get the boost svn mirror
git clone http://github.com/ryppl/boost-svn     # takes a couple of minutes

# get the modularization script
git clone http://github.com/ryppl/boost-modularize

To do the modularization once you've prepared these repositories:

cd boost-modularize
python -u modularize.py --src=../boost-svn --dst=../modules setup
python -u modularize.py --src=../boost-svn --dst=../modules update

You won't want to do this, but the automated process goes on to update the ​modularized state at GitHub:

python -u modularize.py --src=../boost-svn --dst=../modules push

Integration Testing

The other columns represent the results of Boost "integration tests" of the modularized state on several platforms. An integration test is essentially equivalent to Boost's official unmodularized tests: we run all of the libraries' tests together, with the latest state of each library. Each time there's a change in the modularized state, we kick off integration tests.

To run integration test on a local machine, start in a clone of the modularized state:

# get the the modularized boost superproject
git clone http://github.com/boost-libs/boost modules

# Update all the submodules
cd modules
git submodule update --init                     # takes a couple of minutes

Then create a build directory so you don't mess up the source tree:

mkdir ../build

Finally, configure, build, and test:

cmake -DBUILDDIR=../build -DBUILDSTEP=configure -DTOOLCHAIN= -P build.cmake
cmake -DBUILDDIR=../build -DBUILDSTEP=build -DTOOLCHAIN= -P build.cmake
cmake -DBUILDDIR=../build -DBUILDSTEP=test -DTOOLCHAIN= -P build.cmake

TODOs

Porting Test Jamfiles

The integration testing columns are currently not all green in part because several libraries have not had the Jamfiles for their tests ported to CMake yet (all Jamfiles for building library binaries have been ported). ​These tickets document the libraries whose test Jamfiles have been ported, and ​these show the libraries whose Jamfiles still need to be ported. Most of these should be really straightforward to handle based on looking at Jamfiles and examples of ​commits that closed unit test tickets (follow the link in each ticket).

For a more complex example, see the ​CMake file for Boost.Python, graciously ported by Ravikiran Rajagopal. These are among the most complex because they have to invoke Python instead of just building and running C++ executables.

Porting Documentation Jamfiles

Libraries with generated documentation (e.g. via Quickbook, ​Docbook, or ​RestructuredText) need to have their Jamfiles ported as well. There's a list of tickets ​here.

Rewriting Boost History

Several methods have been discussed for preserving the history of Boost in the modularized git repositories; we still have to settle on and implement one approach. The easiest to implement, though not necessarily the most useful possible arrangement, would be to simply allow people to graft the Boost SVN history onto their modularized Git repository.

Further Testing

There are several levels at which we might want to confirm that the CMake build instructions are doing the same thing that the Boost.Build Jamfiles are.

How Can I Help?

Read the section on porting test Jamfiles and close a few of the ​open tickets. Most of these should be easy even if you don't know much about Boost.Build or CMake!