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

Subject: Re: [Boost-cmake] Variant Builds and missing libraries
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-11-29 02:59:30

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

Yes, it does. I think that for compiled libraries, it's a good idea to
have both static and shared linking tested, whereas for header-only
libraries, the chances that static/shared linking affects anything are
close to zero. Therefore, test arrangement where header-only libraries
are tested in one variant, and compiled libraries are tested in
both static and shared variants appears to be a reasonable compomise
between testing speed and coverage.
 
- Volodya