Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] Variant Builds and missing libraries
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2008-11-12 14:21:23


On Nov 12, 2008, at 11:39 AM, David Abrahams wrote:

>
> on Wed Nov 12 2008, Michael Jackson <mike.jackson-AT-bluequartz.net>
> wrote:
>
>> Came across an interesting situation while doing some testing on the
>> CMake build system. I configured my build tree to be SHARED+MULTI-
>> THREADED+DEBUG. When I built I was almost immediately getting an
>> error
>> about not being able to link against boost_test_exec_monitor-mt-
>> shared. Which is wrong because test_exec_monitor is a static-only
>> library. As I walked through the CMake code to track down what was
>> the
>> problem I basically discovered for myself that if you have
>> BUILD_STATIC=OFF then NO static libraries will be built, which has
>> the
>> side effect of disabling any regression test that relies on the
>> test_exec_monitor.
>>
>> Question: Is this desired behavior? (I wouldn't think so but I
>> would rather hear that from a boost dev)
>
> Well, you'd need a Boost-CMake dev, of which there are few, to tell
> you
> what BUILD_STATIC=OFF is supposed to mean. However, my guess is that
> it's really for deciding which library variants you're going to build
> and install, not what can get built as part of a dependency chain.
> Frankly, even in the build/install case, it seems implausible that
> people could be unhappy when a static-only library is built statically
> when the shared variant is requested. I would err on the side of
> building rather than not building, and let people use --without-
> libname
> or whatever its CMake equivalent is if they want to leave it out.

I chatted with Volodya on the #boost irc channel and basically if you
are doing regression testing then all the variants are built. By
default a regression test will link against the debug, Single
Threaded, Shared Linking library. If those libraries are NOT available
then they are built so basically turning ON testing will enable ALL
variants to be built.
   The doesn't affect the boost user who just wants to build the
libraries and install them. That user can still select what variants
to be built and installed.

>
>> Comment: I have a solution in place where I added another optional
>> argument to the boost_add_library macro that is located in
>> BoostCore.cmake. The argument is FORCE_VARIANTS followed by the type
>> of variant that you want to make. So the call to this macro for the
>> test_exec_monitor looks like the following:
>>
>> boost_add_library(boost_test_exec_monitor
>> NO_SHARED
>> compiler_log_formatter.cpp
>> debug.cpp
>> execution_monitor.cpp
>> framework.cpp
>> plain_report_formatter.cpp
>> progress_monitor.cpp
>> results_collector.cpp
>> results_reporter.cpp
>> test_main.cpp
>> test_tools.cpp
>> unit_test_log.cpp
>> unit_test_main.cpp
>> unit_test_monitor.cpp
>> unit_test_parameters.cpp
>> unit_test_suite.cpp
>> xml_log_formatter.cpp
>> xml_report_formatter.cpp
>> FORCE_VARIANTS STATIC
>> )
>>
>> This takes care of case where boost_test_exec_monitor was NOT being
>> built but I still have the case of adding a regression test does not
>> work. From boost/libs/config/test/CMakeLists.txt:
>>
>> boost_test_run(limits_test DEPENDS boost_test_exec_monitor)
>>
>> which will still fail because the current cmake code will look for
>> some other variant (MT-SHARED) of the boost_test_exec_monitor
>> library.
>
> Problem.
>
>
>> Question: Should I somehow hard code into boost_test_run() a
>> conditional test for the test_exec_monitor library being needed and
>> link to the proper library?
>
> Better than nothing, but...
>
>> Somehow seems "wrong" to do it that way.
>
> Yep.
>
>> I really feel like I am missing something that probably was already
>> implemented.
>
> IMO, NO_SHARED should mean when looking for a shared variant, pick the
> static one instead... and vice versa for NO_STATIC if we have that.

You are correct and in fact it is that way in the CMake code.
Currently the way things are setup if I select to NOT have static
libraries built AND then try to build the regression tests then the
compilation will fail because the static libraries that the regression
test may be asking for are NOT built.

   Probably the best approach is if the user enables the
"BUILD_TESTING" option then I'll have to enable all variants of the
libraries to also be built. This would parallel what boost.build does
currently.

>
> Cheers,
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com


Boost-cmake list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk