Re: [Boost-build] allowing targets to fail

Subject: Re: [Boost-build] allowing targets to fail
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-04-08 22:52:54

AMDG

On 04/08/2017 04:22 PM, Stefan Seefeld via Boost-build wrote:
> On 08.04.2017 13:31, Steven Watanabe via Boost-build wrote:
>> 
>> On 04/08/2017 11:00 AM, Stefan Seefeld via Boost-build wrote:
>>
>>> Can you qualify "immediately" and "later" a little more ?
>>   Immediately means that we call UPDATE_NOW
>> directly.
> 
> Directly where, in what phase of the workflow ? This may seem pedantic,
> but I think it's important to spell out in full detail so users of those
> features understand the implications.
> 

This happens as a part of computing the common properties.
Step 3 here:
http://www.boost.org/build/doc/html/bbv2/overview/build_process.html#idp88056016

>>   Later means that we add the target
>> to dependency graph and assume that someone
>> else will call UPDATE_NOW.
> 
> To rephrase my question above: I understand the there is a top-level
> call to UPDATE_NOW, where the arguments are the targets explicitly
> requested from command-line options (and associated properties). So all
> those other calls to UPDATE_NOW must be triggered through some other
> mechanism by which the (or another ?) dependency graph is evaluated,
> eventually leading to those "immediate" targets.
> In other words, it seems there are multiple ways in which the (or a)
> dependency graph is traversed: the one used by the bjam engine itself
> ("phase 3" as per your description), and the others sometime earlier,
> while that dependency graph is constructed ("phase 2" as per your
> description).
> 
> Am I capturing the situation correctly with that description ?
> 

  That's about right.  The key is that UPDATE_NOW doesn't
require the dependency graph to be globally complete.
It only needs the subgraph that it is actually updating
to be ready.

>>> Normal targets
>>> (those being built "later", that is) are only built if either explicitly
>>> requested or needed by explicitly requested dependent targets.
>>> But, for these "immediate" targets this doesn't seem to be possible, or
>>> does it ?
>>   Boost.Build only generates the actual targets
>> which are needed.  check-target-builds will only
>> be evaluated if we are building the target that
>> uses it.
> 
> This is where I'm (slightly) confused: to me it doesn't look like any
> real target "uses" the check-target-builds target. Rather, it's the
> 'main' *meta*-target that requires it in the target instantiation process.
> 

Right.  There isn't an actual dependency via DEPENDS.

In Christ,
Steven Watanabe