on Sat Dec 31 2011, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus
hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Glad you asked! That wiki page is (fortunately) out of date. We currently have an automated process modularizing boost each time there's a new commit. It uses this script <http://github.com/ryppl/boost-modularize> which you can see at <https://github.com/ryppl/boost-modularize/commits> is being kept up-to-date by Daniel Pfeifer. You can view the status right here: http://j.mp/boost-modularization-bot [1] (if you see many or all of the buildslaves offline it's because I'm reorganizing things a bit at the moment) What you're seeing in the right-hand column is the modularization process itself: it's operating on a mirror of the Boost SVN, and splitting up the files into separate git repositories (at https://github.com/boost-lib) according to their respective projects. If that column is green, it tells you that all files are currently accounted for. Here's what happens if there are files that don't have a known modularization home: http://j.mp/boost-modularization-failure [2] (In that run, it looks like someone just added the Boost.Heap library and it needed to be accounted for). When that happens, Daniel get an email and he fixes it. The other columns represent the results of Boost "integration tests" on the modularized state. An integration test is essentially equivalent to what we're doing today for Boost: run all of the libraries' tests together. Each time there's a new modularization, integration testing is done on several platforms. Now, the reason those columns are not all green is that a bunch of libraries have not had their tests and documentation builds ported to CMake yet. Daniel has opened a ticket for each one of those: https://github.com/ryppl/boost-modularize/issues Most of these should be really straightforward to handle. For examples of test CMake files, have a look at the commits that closed these issues: http://j.mp/cmake-ified-boost-tests [3] ,----[ You can Help ] | It would be great to close more of these issues. Most should be very easy. `---- Ravikiran Rajagopal graciously ported the Python tests, which are among the most complex because they have to invoke Python instead of just building and running C++ executables (<https://github.com/boost-lib/python/blob/master/test/CMakeLists.txt>). Footnotes: [1] <http://bbot.boostpro.com/waterfall?show_events=true&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&builder=Boost.Modularize-x-Modularize&reload=none> [2] <http://bbot.boostpro.com/builders/Boost.Modularize-x-Modularize/builds/1343/steps/modularize%28update%29/logs/stdio> [3] <https://github.com/ryppl/boost-modularize/issues/search?q=unit+tests&state=closed> -- Dave Abrahams BoostPro Computing http://www.boostpro.com