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

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

On Nov 26, 2008, at 9:32 AM, Vladimir Prus wrote:

> Michael Jackson wrote:
>
>>
>> On Nov 13, 2008, at 12:31 PM, Vladimir Prus wrote:
>>
>>> Michael Jackson wrote:
>>>
>>>>
>>>> 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.
>>>
>>> Err, I did not say that. I said that Boost.Build does not need any
>>> up-front
>>> build of anything -- if you want to run regressions with specific
>>> properties,
>>> it will build all that's needed.
>>>
>>> - Volodya
>>>
>>>
>>
>> That was my basic interpretation. Basically, if you are building the
>> regression tests then you will need all the variants because at some
>> point all the variants are most likely used.
>
> We seem to be miscommunicating on this point :-( Why
> "all the variants are most likely used"? If I'm running test with
> variant=debug link=shared, then I don't need variant=release, ever.
>
>> I can start putting logic into the cmake files to make sure the  
>> proper
>> variants are built but it is just easier to build all of them if you
>> are going to be running tests. I am interested to hear all the
>> arguments either way.
>
> You'll be just wasting disk space with 8 variants of libraries, where
> only 1 is needed. And debug variants are huge.
>
> - Volodya

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.

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

Some one will also need to add to the boost_add_test to make sure all  
the variants of the test are correctly built if asked for. The logic  
for all of this will be quite "interesting" to implement.

Are these things that the boost community wants in the cmake system?  
Basically to have the same behavior as bjam? Was the boost community  
wanting to move in another direction with the CMake build system? I am  
just trying to figure out where I might want to put my efforts.

Thanks for all the helpful feedback.
_________________________________________________________
Mike Jackson                  mike.jackson_at_[hidden]
             www.bluequartz.net