Subject: Re: [Boost-build] allowing targets to fail
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-04-08 22:52:54
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 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:
>> 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
> 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.
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