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-30 10:44:56

Michael Jackson wrote:

> 
> On Nov 29, 2008, at 2:59 AM, Vladimir Prus wrote:
> 
>> 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
> 
> 
> So are you saying you would want to see cmake test all variants in a
> single build directory or have multiple build directories, one for
> each variant?

It want to have both shared and static flavours of program_options tested without
running all the Spirit (*) tests in both modes. I presume this means that
it should be possible to build and test both shared and static flavours of
program_options in a single build tree.

(*) Spirit is an example of a library that is both advanced enough to require
non-zero testing resources, and which is header-only.

- Volodya