Boost Interest :
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
>> 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 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
> 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.