Re: [Boost-build] feature, properties, variants, and all the rest

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-08-04 00:37:17

AMDG

On 08/03/2017 03:57 PM, Stefan Seefeld via Boost-build wrote:
> 
> Consider again my earlier example, where the target "C" depends on some
> config checks "A" and "B", during the update of which some properties
> will be set that are used to build C.
> I think the spelling was
> 
> exe C : C.cpp : [ check-target-builds B : <use>B ] ;
> 
> So, let's assume that one of the usage requirements of "B" affects the
> choice of the toolset, or some other essential property that influences
> the qualified filename .../C.exe.

  That's not allowed.  Only free features can be
used in usage-requirements.  The appending
behavior of free features is necessary.  If
usage requirements can override properties, then
it's essentially impossible to maintain consistency.
Even so, targets are not bound to specific filesystem
paths until quite late.  Processing the usage
requirements of B happens long before we try find
a sequence of generators that can create an executable
from a .cpp file.

> My point simply was that, at the time `b2 C` is invoked, nothing is
> known yet about .../C.exe. It's the generator action associated with
> C-gen that will inject a new target for .../C.exe, and make it a
> prerequisite of C to tell b2 to build that as part of building C.
> 

  C and C.exe exist at different layers of Boost.Build.
calling [ targets.generate-from-reference C :
          $(project) : $(property-set) ]
will give you back a virtual-target representing C.exe.
It sounds like you're thinking that there's a
dependency of C on C.exe, but there's no such thing,
because they're totally different things.

>>> <snip>
>>>> main-target.construct(properties) returns a list of virtual targets.
>>>> virtual-target.actualize() returns a Jam target.
>>> OK. But given that at least in my earlier case with config checks
>>> affecting the properties passed down to main-target.construct(),
>>   That's not quite correct.  main-target.generate
>> (I got the name wrong.  The top-level interface
>> that builds the dependency graph is called generate
>> not construct.) processes conditional properties,
>> including config checks.
> 
> That's exactly my point.  main-target.generate would be invoked as part
> of the "C-gen" update above (in my model), no ?

I'm lost.

> I know. But as far as I understand, this is only needed as the only way
> to get back the status of the target (i.e., whether it was built
> successfully or not).
> My whole question gravitates around the entire build process (including
> the injection of new intermediate targets) being done in a single stage,
> rather than requiring multiple distinct "config; make; test" stages.
> 

  Saying that the build process only has a single
stage is somewhat misleading.  Originally, Boost.Build
was separated into distinct phases, but configure checks,
which were added later on, call back to the top level
recursively somewhat muddying the waters.

In Christ,
Steven Watanabe