|
Boost-Build : |
Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-02 02:24:10
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.
You start the enumeration of steps with "building C", though there is a
whole lot going on before that: The dependency graph needs to be
instantiated first. For example, to link "C" to "C.cpp" some generator
logic needs to be invoked that may want to inspect the properties
defined for C to figure out a set of tools able to make C from C.cpp. So
what properties are being used by the generator logic, and how do they
use conditionals (if at all) ?
Thanks,
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk