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 14:46:51

Hi Steven,

thanks for the quick reply !

On 08.04.2017 10:13, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 04/08/2017 06:31 AM, Stefan Seefeld via Boost-build wrote:
>> 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" ?
>>
> 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 ?

> 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 ? 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.

Conceptually this seems like a two-phase 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 ?). 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.

>
> When loading Jamfiles we create a data structure that
> looks something like this:
>
> class basic-target {
>     # returns a list of targets to build and the usage-requirements
>     pair<target-list, property-set> construct(property-set);
> }
> # Constructing a project builds all targets in the project
> class project-target : basic-target {}
>
> # Corresponds to a single named target in a Jamfile
> class main-target : basic-target {}
>
> Then pseudo-code for the build looks something like:
>
> project = load-jamfile(".");
> (targets, usage-requirements) =
>   project.construct(command-line-features);
> bjam.update-now $(targets) ;
>
> In Christ,
> Steven Watanabe

Thanks,
        Stefan

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