Boost logo

Boost-Build :

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at