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

Subject: Re: [Boost-cmake] Variant Builds and missing libraries
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2008-11-29 09:20:52

On Nov 28, 2008, at 4:49 PM, David Abrahams wrote:

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

Didn't know about that page. Thanks. It does help explain what I am  
seeing.

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

No alternative, just a newbie noticing (and verifying) behavior.

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

    CMake's approach would be to make a separate build directory for  
each build variant that was to be compiled/tested. So on Linux for  
example you would potentially end up with 16 build directories. At  
this point there is "support" for multiple variants within one CMake  
build directory which is sort of "abusing" cmake a bit but does seem  
to work at least for building the libraries.

    In a "CMake" world and using the example from above, if a test  
requires a static-multi-threaded build of a library BUT the user has  
asked for a dynamic-multi-threaded then that test would not be built.  
This is the current implemented behavior. This means that there is NO  
attempt to build a static-multi-threaded library because a test  
required it.

    The test reporting will have to make these configuration choices  
clear so that results can be easily and quickly reviewed.

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

External build scripts and such could be a reasonable choice. The only  
thing I don't like about external scripts is that they are generally  
NOT cross-platform and you end up writing a script for windows and one  
for Unix.

I'm happy to help the boost community implement what ever style we  
decide on in the end.

_________________________________________________________
Mike Jackson                  mike.jackson_at_[hidden]
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio