Re: [Boost-build] allowing targets to fail

Subject: Re: [Boost-build] allowing targets to fail
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-04-08 12:31:55

On 01.04.2017 08:51, Rene Rivera wrote:
> On Sat, Apr 1, 2017 at 6:53 AM, Stefan Seefeld via Boost-build
> <boost-build_at_[hidden] <mailto:boost-build_at_[hidden]>> wrote:
>
>     On 31.03.2017 13 <tel:31.03.2017%2013>:35, Steven Watanabe via
>     Boost-build wrote:
>     > AMDG
>     >
>     > On 03/31/2017 11:14 AM, Stefan Seefeld via Boost-build wrote:
>     >> Ah, interesting ! So this provides a mechanism to capture a
>     target's
>     >> result while still letting if fail. But it seems this comes at
>     a price:
>     >> To be able to capture results of individual target builds, I
>     need to
>     >> submit them individually (via "UPDATE_NOW"), which precludes
>     >> parallelization.
>     >> If I submit multiple targets at once, I only get the overall
>     success
>     >> back. Correct ?
>     >   Yep.  As a workaround, you can batch them, and
>     > then call UPDATE_NOW again individually to get
>     > the results.  UPDATE_NOW never tries to build
>     > any target more than once, no matter how many times
>     > it is called from the same b2 process.
>
>     I'm actually wondering whether that's (necessary) true: Is the bjam
>     engine thread-safe ? If I run `b2 -j 8`, may I invoke UPDATE_NOW from
>     one action and expect other targets to continue to be built in
>     parallel
>     ? Would that break ? Or would that serialize the execution ?
>
>
> None of the above. Yes, the engine is parallel-safe. But that is
> irrelevant for this question. All targets are built with the same
> mechanism at the low level. The differences for UPDATE_NOW are when it
> executes the actions and how it waits for them. Regular action
> execution happens after the parsing/evaluation of the b2 files during
> the make stages. UPDATE_NOW happens during the parsing/evaluation and
> blocks it until the actions complete. So there's no question about
> thread safety, or parallel safety, since b2 is single threaded anyway.

I'm still trying to understand how this works...

Consider this little snippet (from example/try_compile/)

  obj foo : foo.cpp ;
  exe main : main.cpp : [ check-target-builds foo : <define>FOO=1 :
<define>FOO=0 ] ;

I can add an "ECHO done parsing ;" at the end of the Jamfile to
demonstrate that the "check-target-builds" rule isn't executed during
the parsing. But when is it executed ? Or more generally: what does the
overall data- and workflow look like ? The "define" feature (or property
?) can only be defined once the build result of "foo" is known, which
seems to rule out that it is done during the normal make stage. Or does it ?
Could someone please spell out all the build / evaluation stages for the
above snippet ? When is "foo" built ? When is the "define" property set
on the "main" target ? Etc. ? And given the above conditional definition
of properties, what else may be conditionalized on the outcome of a
target build such as "foo" ?

Many thanks,
        Stefan

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