Re: [Boost-cmake] Variant Builds and missing libraries

Subject: Re: [Boost-cmake] Variant Builds and missing libraries
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-28 16:49:18

on Wed Nov 26 2008, Michael Jackson <mike.jackson-AT-bluequartz.net> wrote:

> Taking a deeper look into this issue (by experimenting with bjam) this
> is what I am seeing (at least on OS X).
>
> bjam errors on the side of building if I don't quite give it the right
> information. For instance in the program_options testing I do the
> following:
>
>   bjam cmdline_test_dll toolset=darwin variant=debug link=static
>
> and I actually get a shared program_options library built, which is what the
> regression test needs, but I don't actually get a static  program_options library
> built.

Because the regression test doesn't need it.  That's not erring on the
side of building; that's erring on the side of doing what's specified by
the Jamfile if it conflicts with the command-line.

There's some rationale for that
(http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection#Example2)
even though Boost.Build doesn't hew to that rationale consistently.

> I also noticed that if I start adding multiple configurations (like
> single and multi-threading) I will get multiple versions of the
> regression test created. 

I can't see what possible alternative you could have expected.

> (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.

> 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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com