Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] Variant Builds and missing libraries
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-11-28 17:12:06


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



Boost-cmake list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk