On Fri, Nov 28, 2008 at 4:49 PM, David Abrahams <dave@boostpro.com> wrote:

> (Which answered another question that I was going to ask).
>
> Currently the CMake system will NOT do any of this. If this is the
> behavior that is wanted then the logic will need to be added to the
> cmake build files.

IIUC, CMake doesn't naturally build multiple variants in one build
command.  It was my conclusion, along with Doug G., that such
multiple-configuration builds should be handled by an external driver
script rather than trying to get CMake to do something for which it
isn't designed.  I'm not sure how well that fits with Boost's testing
regime, though.  When I look at the Jamfile for program_options it seems
to be specifying two specific configurations to test.

I was one of people who was initially concerned about building and testing multiple variants with a single command. But I think an external script would be fine. There may even be an advantage - it may be easier to debug problems since CMake isn't trying to do so much.

> Some one will also need to add to the boost_add_test to make sure all
> the variants of the test are correctly built if asked for. The logic
> for all of this will be quite "interesting" to implement.
>
> Are these things that the boost community wants in the cmake system?
> Basically to have the same behavior as bjam?

IMO we should think very carefully before moving in that direction.
There are lots of good design ideas in bjam but not everything we did
there ultimately ends up helping.  In particular, the "separate
configuration step" design of cmake (and autoconf) seems to have some
advantages over the "one big build step" approach of Boost.Build, and
the former is linked, at least partially, to the "one variant per
invocation" design of CMake.

Boost.Build is a wonderful system when it works, but the complexity is such that I find it very hard to debug build and test problems. We need to be careful that we don't create the same problem with CMake by loading it up with too many features.

I'm particularly concerned with the reporting of test results. Is there any progress in that area? Dave, are you actively working on test result displays?

--Beman