= CMake TODO List =

These are some features that we would like to implement in the CMake-based build system for Boost (in no particular order).

  * Many libraries have empty or incomplete CMakeLists.txt.  Review the CMakeLists.txt files against the Jamfile.v2 files and 
    synchronize.
  * Triage or fix bugs reported against the CMake component in Trac
  * Regression testing:
    * For each library, automatically introduce a test that uses the "inspect" program to verify that the library meets all of Boost's coding and licensing requirements (and anything else that inspect checks).
  * Modularization of documentation generation, so documentation for a single library can be generated and installed along with documentation for the other libraries.
  * Determine how the "tools" directory should fit in with "libs". Right now, "tools" is disabled because it doesn't work well with modular libraries.
  * Building and testing against an installed tree:
    * Allow a single Boost component's sources to be downloaded and built against an installed Boost
    * Allow regression tests to be built and executed against an installed Boost
    * Update regression-testing scripts to simulate a user's usage: build a Boost tree, build its installer, execute the installer, build the regression tests against the installed version (separately!), run regression tests and report the results.
    * Can one download, configure, and install a subset of components built against an installed tree and each other?
  * "Modularize" the rest of the Boost libraries
  * Add description, author, and maintainer information to the CMakeLists.txt files for all of the libraries.
  * Testing on more platforms and tweaks for those platforms
  * Add CMakeLists.txt files for regression tests for libraries new in 1.35.0 that don't already have them, e.g., asio.
  * Generate and install pkgconfig files, so that Boost libraries can be found via pkgconfig

== Downstream tools ==

For CMake to fully replace Boost.Build, the special needs of developers and testers must be addressed. The "tools" needed may be in the form of documentation and python scripts rather than CMake tools.

  * Provide a tool for developers that lets them test locally on their own machines, and see the results in both summary and detail forms. Tests likely involve multiple compilers and may also include multiple configurations for each compiler.

  * Provide a highly-robust and self-bootstrapping tool for testers. Should be able to run unattended for months and months. Must be a "good citizen" and manage space, time, and bandwidth resources prudently.