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.

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.

TODOs

The integration testing columns are currently not all green in part because several libraries have not had their test Jamfiles ported to CMake yet. ​These tickets document the libraries whose test Jamfiles have been ported, and ​these are 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.