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 15:28:42

AMDG

On 04/08/2017 08:46 AM, Stefan Seefeld via Boost-build wrote:
> 
> On 08.04.2017 10:13, Steven Watanabe via Boost-build wrote:
>> 
>> Phase 1: Load Jamfiles
>> Phase 2: Generate actual targets
>> Phase 3: Build targets
> 
> OK. And the parallel execution (requested via the "-j" option) would
> only affect phase 3 ?
> 

  Yes.  In theory, if check-target-builds has
to update multiple targets it can build them
in parallel.  However, it's usually used to
build one target at a time.  I've considered
ways to allow check-target-builds to be fully
asynchronous and allow these checks to build
in parallel, but this would require almost a
total rewrite.

>> All properties including check-target-build are handled
>> in phase 2.
> 
> I see ! That means that the target argument passed to the
> "check-target-build" ("foo" in my case above) isn't itself considered a
> regular target, or somehow gets special treatment. Right ?

  This is just a high level view.  The implementation
allows both generating targets and building targets
to be handled on a per-target basis.  The special treatment
is just that foo gets processed immediately instead of
being built later.

> Are there any
> restrictions on what "foo" might be ? (In the above case it's itself a
> target created with the "obj" meta-target rule, so I'd assume it could
> be anything.
> 

It can be any target.

> Conceptually this seems like a two-phase build,

  It's actually more of a N-phase build.
The targets used by check-target-builds
can themselves use check-target-builds.
The process of building the targets used
by check-target-builds is identical to the
main build.

> where a first pass
> filters out all those "check-target-build" targets and builds those, to
> evaluate dependent properties (what other effects may these have other
> than defining properties ?).

  It's implemented as a <conditional> which can
only affect properties.  However, properties
can affect anything.

> And the second phase then would be the
> regular build, with all properties fixed.
> 
> In the autotools world this corresponds of course to the separation of
> the "configure" and "make" steps, so this isn't unusual.
> 

In Christ,
Steven Watanabe