Re: [Boost-cmake] Regression Test Reporting (Was: Variant Builds and missing libraries)

Subject: Re: [Boost-cmake] Regression Test Reporting (Was: Variant Builds and missing libraries)
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2008-11-30 10:39:54

On Nov 28, 2008, at 5:12 PM, Beman Dawes wrote:

>
>
> On Fri, Nov 28, 2008 at 4:49 PM, David Abrahams <dave_at_[hidden]>  
> 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

Are we still looking at combining ctest with trac? IIRC there was a  
"traash" plugin for TRAC? Was CTest and CDash ever tried out to see  
how useful they could be?
_________________________________________________________
Mike Jackson                  mike.jackson_at_[hidden]
             www.bluequartz.net