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 17:33:25

On 1/26/2016 12:44 PM, Steven Watanabe wrote:
> AMDG
>
> On 01/25/2016 11:47 PM, Edward Diener wrote:
>>
>> Where are conditional and non-conditional properties of a target
>> discussed ?
>>
>
> Conditional requirements are discussed here:
> http://www.boost.org/build/doc/html/bbv2/tutorial/conditions.html

Does this imply that a non-conditional property can never be overridden 
by a build request ?

>
>> Is there a way to see ( or trace ) during a build request how a
>> particular property's value for a particular target is decided ?
>>
>
> --debug-building should show this.

OK, I will try this.

>
>> 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.
>>
>
> i.e. default-build vs. requirements?
> http://www.boost.org/build/doc/html/bbv2/overview/targets.html#idp87999872
>
> "Requirements
>
> Requirements are the properties that should always be present when
> building a target. "
>
> "Default Build
>
> The default-build parameter is a set of properties to be used if the
> build request does not otherwise specify a value for features in the set"

That is not really what I want.

I want to understand the rules by which a property is set, given that 
the property can be set for a target in a number of different places, 
including a toolset's configuration and the end-user's command line.

What I keep gathering is that the rules deciding the final value of a 
property for a target are so complex that it is nearly impossible for 
the end-user to understand them. What I am suggesting is that it should 
be possible to understand this process by the end-user and if Boost 
Build is so complex that it is nearly impossible to do so that this is a 
failing in the design of Boost Build. After all an end-user, specifying 
a property's value should be able to know how/if this property is being 
applied to a particular build.