Boost Interest :
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)
>>>> 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
>>>> information. For instance in the program_options testing I do the
>>>> 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
>>> Because the regression test doesn't need it. That's not erring on
>>> 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
>>> 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
>>> 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.