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 17:48:19

On 29.07.2017 11:24, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 07/29/2017 08:53 AM, Stefan Seefeld via Boost-build wrote:
>> 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 ?
>>
> This particular scenario would look something like:
>
> obj A : a.cpp : : <include>/a/path ;
> obj B : b.cpp : [ check-target-builds A : <use>A ] ;
> exe C : C.cpp : [ check-target-builds B : <use>B ]
>
> Now, when building C, it will go something like this:
> - Building C
>   - Building B from check-target-builds
>     - Building A from check-target builds
>       - A builds successfully
>     - Applying property <use>A
>     - Common properties for B: <use>A
>     - Building dependencies of B
>       - Building A - reuse existing target
>     - Apply usage-requirements from A
>     - Properties for B: <include>/a/path
>     - Usage requirements for B: <include>/a/path (Usage
>       requirements propagate up from A)
>   - B builds successfully
>   - Applying property <use>B
>   - Build B and get usage-requirements
>   - Build C.o with <include>/a/path
>
> If either A or B fails to build, then the corresponding
> <use>A or <use>B will not be applied and the usage-requirement
> <include>/a/path will stop propagating upwards.

OK. I suppose instead of the explicit "<include>/a/path" I could also
write an action (used to build A) that determines "/a/path", yes ? How
would I push that onto the usage requirements of A ?

Thanks,
        Stefan

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