Re: [boost] boost modularisation status?

Subject: Re: [boost] boost modularisation status?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-12-31 19:33:56

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