Re: [Boost-build] feature, properties, variants, and all the rest

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-29 14:53:39

On 28.07.2017 22:15, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 07/28/2017 07:42 PM, Stefan Seefeld via Boost-build wrote:
>> On 28.07.2017 20:39, Steven Watanabe via Boost-build wrote:
>>> On 07/28/2017 06:00 PM, Stefan Seefeld via Boost-build wrote:
>>>> Indeed. I'm still not entirely sure the semantics are fully unambiguous.
>>>> Consider this use-case:
>>>>
>>>> Target A is a config check, which (conditionally) defines property a.
>>>> Target B, depending on A, defines property b. Target C depends on A and B...
>>>>
>>>> So, a is evaluated in the context of an empty property-set, while b is
>>>> evaluated in the property-set consisting of a. The result is then passed
>>>> on to C.
>>>>
>>>> What happens if B does not depend on A ? That would mean that that
>>>> property b is evaluated in an empty property-set (just as a itself),
>>>> rather than in the context of a, and thus might lead to a different
>>>> property-set passed on to C.
>>>> Correct ?
>>>>
>>>> This is just slightly surprising, as 'B depends on A' merely seems to
>>>> imply an order of execution (A before B), while, if the above is
>>>> correct, this actually influences the property-set seen by C.
>>>>
>>>   I'm not sure that I follow.  When you say
>>> that target A defines property a, do you
>>> mean that a is in the usage requirements of A?
>> Sorry, no. A being a config check, I meant that the value of property a
>> depends on the result of A's update.
>>
>>> Or do you mean that B uses A inside check-target-builds?
>> For B it shouldn't matter how it uses a, just that a (which is a
>> conditional property) needs to be evaluated into the property set seen
>> by B.
>   In other words, yes, it uses check-target-builds, as
> this is the only way for properties to change based
> on whether a target was successfully updated.
>
>> In fact, having reformulated it like this, I think I can rephrase my
>> question:
>>
>> If a is evaluated, is it being evaluated once into B's property set and
>> then propagated to everything else that depends on B ?
>   Properties in the requirements of B are never propagated
> to anything that depends on B.  They are evaluated
> once when building B and then any `propagated` properties
> are passed on to any targets that B depends on.
>
>> Or is it
>> evaluated in multiple contexts ?
>   Conditionals defined on B are only evaluated in the
> context of B.  They are always resolved before
> passing them on to other targets.
>
>> By what logic is its value being propagated into C's property set (if at
>> all) ?
>>
> The requirements of B will never directly affect C.
>
> Okay, example time:
>
> feature a : on : optional ;
> obj A : a.cpp ;
> obj X : X.cpp ;
> lib B : X Y.cpp : [ check-target-builds A : <a>on ] ;
> exe C : B ;
>
> Assume that A builds successfully.
> Y.o and B.a will be built with <a>on (whatever that does).
> X.o and C will /not/ have <a>on.
>
>   If we change the definition of a to
> feature a : on : optional propagated ;
> then X.o will be built with <a>on.  (propagated
> causes a feature to be passed on to dependents)
>
>   If A does not build successfully, then <a>on
> will not be used for any target.
>
>   Is this anything like what you had in mind,
> or am I totally misunderstanding?

I was actually thinking of something rather common when building C/C++,
in particular with autotools:
As a first step, a few config checks are run, to detect certain features
of the build environment. These result in the definition of macros. So I
was thinking of a chain of two such config checks A and B, where A would
check for the presence of a header (say), and B would then attempt to
build a (test) binary with it. If both succeed, the actual executable is
built (let's call that target C). Now let's assume the header check A
also sets a include search path, which is used both to compile target B
and C.

How would that chain of dependencies be expressed with b2 ? What
features and properties are used, and how, to pass the header search
path to B and C ?

Thanks,
        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...