Changes between Version 14 and Version 15 of CMakeModularizationStatus

Timestamp:

Jan 1, 2012, 1:27:19 AM (11 years ago)

Author:

Dave Abrahams

Comment:

Rewrite to reflect current status

CMakeModularizationStatus

@@ -1 +1 @@
 = CMake Modularization Status =
 
-This page is used to keep track of which Boost libraries have been modularized fully and which libraries should be in the unmodularized "core". Any libraries not listed haven't been studied closely enough yet.
 
-== Modularized Libraries ==
+All Boost libraries currently inhabit a [http://svn.boost.org/svn/boost 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
+[http://boost.org/tools/build Boost.Build] to [http://cmake.org CMake].
 
-The following libraries have been fully modularized, which means that (1) all of their headers are listed in a HEADERS argument to boost_library_project, and (2) are listed in the DEPENDS argument for all libraries that depend on them. This second condition can be established by re-building all of the tests after running the modularize target for that library. Once a library has been put into this list, the argument MODULARIZED should be added to its boost_library_project macro, so that it will be modularized as part of the main "modularize" target.
+== Automated Tests ==
 
- * accumulators
- * algorithm
- * asio
- * bimap
- * circular_buffer
- * date_time
- * dynamic_bitset
- * filesystem
- * fusion
- * gil
- * graph
- * interprocess
- * iostreams
- * mpi
- * parameter
- * program_options
- * ptr_container
- * python
- * regex
- * signals
- * spirit
- * statechart
- * system
- * tr1
- * units
- * wave
- * xpressive
+You can review the current status of modularization [http://bbot.boostpro.com/waterfall?show_events=true&builder=Boost.Modularize-x-Modularize&builder=Boost-vc8-win64-Integration&builder=Boost-vc7.1-win64-Integration&builder=Boost-gcc-linux-Integration&builder=Boost-vc10-win64-Integration&builder=Boost-vc9-win64-Integration&reload=none here].
 
-== "Core" Libraries ==
+=== Modularization ===
 
-The following libraries are considered part of the "core" of Boost and should not be modularized at this time. Libraries may be dubbed "core" libraries due to excessive dependencies (e.g., config, type_traits), circular dependencies, or poor separation from the rest of Boost (e.g., utility). We hope that future refactoring will remove most libraries from "core" status.
+Each time there's a new commit to Boost's trunk, [http://github.com/ryppl/boost-modularize this script]
+modularizes a [http://github.com/ryppl/boost-svn Git repository mirroring Boost SVN]
+and distributes the updated files into separate [http://github.com/boost-lib per-library git repositories].
+As [https://github.com/ryppl/boost-modularize/commits you can see], the script is being kept
+up-to-date by Daniel Pfeifer.
 
- * config
- * mpl
- * preprocessor
- * type_traits
- * utility
+The column labelled “Boost.Modularize” on the right side of the [http://bbot.boostpro.com/waterfall?show_events=true&builder=Boost.Modularize-x-Modularize&builder=Boost-vc8-win64-Integration&builder=Boost-vc7.1-win64-Integration&builder=Boost-gcc-linux-Integration&builder=Boost-vc10-win64-Integration&builder=Boost-vc9-win64-Integration&reload=none 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 [http://bbot.boostpro.com/builders/Boost.Modularize-x-Modularize/builds/1343/steps/modularize%28update%29/logs/stdio 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.
 
-== Unexpected Dependencies ==
+=== Integration Testing ===
 
-This is a simple catalog of inter-library dependencies that were a surprise. We should revisit these dependencies at some point to determine whether they are justified or whether we should try to decouple the libraries.
+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 [http://www.boost.org/development/tests/trunk/developer/summary.html 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.
 
- * spirit -> xpressive: Spirit uses Proto, which is currently part of Xpressive. Eventually, Proto will become its own top-level library, and we'll eliminate this dependency.
- * parameter -> python: Parameter uses one of the Python detail headers, and has the header boost/parameter/python.hpp that might actually belong in the Python library itself.
+=== 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.  [https://github.com/ryppl/boost-modularize/issues/search?q=unit+tests&state=closed These tickets] document the libraries whose test Jamfiles have been ported, and [https://github.com/ryppl/boost-modularize/issues/search?q=unit+tests&state=open 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 [https://github.com/ryppl/boost-modularize/issues/search?q=unit+tests&state=closed closed unit test tickets] (follow the link in each ticket).
+
+For a more complex example, see the [https://github.com/boost-lib/python/blob/master/test/CMakeLists.txt 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.