Re: [Boost-build] Should link=static disable all shared library tests?

Subject: Re: [Boost-build] Should link=static disable all shared library tests?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-01-26 01:47:18

On 1/25/2016 1:59 PM, Vladimir Prus wrote:
> On 24-Jan-16 7:48 AM, Edward Diener wrote:
>> On 1/23/2016 10:11 PM, Steven Watanabe wrote:
>>> AMDG
>>>
>>> On 01/23/2016 07:47 PM, Kuhl, Brian wrote:
>>>> I'm invoking the boost test suite with command similar to the one
>>>> below:
>>>>
>>>> source  ./$(VXWORKS_ENV_SH) &&  cd status   &&  \
>>>>                 ../b2 -j$(JOBS) --prefix=$(ROOT_DIR)
>>>> --libdir=$(LIBDIR)/$(TOOL_COMMON_DIR)
>>>> --includedir=$(VSB_DIR)/usr/h/public   \
>>>>                                   link=static toolset=gcc-vxworks
>>>> target-os=vxworks
>>>> testing.launcher=./vxworks_boost_test_run.exp \
>>>>
>>>> "--limit-tests=atomic|date_time|accumulators|algorithm|align|array|assert"
>>>>
>>>>
>>>> Several library tests are failing because of the lack of shared
>>>> libraries, despite the designation of link=static.
>>>> So far I've encountered tests in system, random and filesystem that
>>>> insist on trying to link against shared libraries..
>>>>
>>>> Is this expected behavior for some reason, or a defect that should
>>>> be corrected?
>>>> Looking at the regression targets I don't see any that would
>>>> typically use static linking.
>>>>
>>>
>>>    This behavior is expected.  Boost.Random
>>> explicitly runs the same test with both
>>> static and shared libraries.  I assume
>>> it's the same for the others.  In any case,
>>> the target properties override anything specified
>>> on the command line.
>>
>> I find it very mysterious that the command line does not override
>> everything else in Boost Build. I have also found it
>> nearly impossible to determine what overrides what when it comes to
>> Boost Build properties. It does not appear to be
>> documented anywhere and my past attempts at finding out what is the
>> hierarchy which determines how a property is set,
>> when it is specified in different places in jamfiles and on the
>> command line, have never been answered. Can an attempt
>> please be made in the documentation to explain this ?
>
> Hi Edward,
>
> I think this aspect is documented at
> http://www.boost.org/build/doc/html/bbv2/reference/buildprocess.html,
> where it say:
>
>      A non-conditional property in requirement in always present in
> common properties.

Shouldn't this read:

"A non-conditional property in requirements is always present in
common properties."

>
> Could you read that page and tell whether anything can be explained better?

Where are conditional and non-conditional properties of a target discussed ?

Is there a way to see ( or trace ) during a build request how a 
particular property's value for a particular target is decided ?

What would seem useful to me is that there would be properties of a 
target which could be overridden by a build request and properties of a 
target that could not be overridden by a build request, and that the 
end-user could distinguish between the two cases.