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-05 20:15:53

AMDG

On 08/04/2017 06:22 AM, Stefan Seefeld via Boost-build wrote:
> On 04.08.2017 00:41, Steven Watanabe via Boost-build wrote:
>>> <snip>
>>> Can you elaborate ? (I believe I understand the distinction between
>>> "main targets", "virtual targets", and "jam targets". However, from an
>>> operational POV, I wonder what happens: If I invoke `b2 C`, "C" is
>>> recognized as a target, so needs to correspond to something the
>>> scheduler knows, right ? Similarly, if I want `b2 C` to actually build
>>> some .../C.exe, I need to make that .../C.exe a prerequisite of C, no ?
>>> (If not, can you please outline to logic leading to the making of
>>> .../C.exe from the invocation of `b2 C` ?)
>>   It's pretty simple.  The list of main targets is
>> lowered to a list of virtual-targets.  These virtual-targets
>> are then lowered to Jam targets which are passed to
>> the engine.
> 
> When does this lowering happen in b2 ? I thought this was managed by the
> engine itself

  Why would you think that?  I just stated that
the engine only gets involved when the Jam targets
are passed to it.  (I'm considering the Jam interpreter
to be separate from the build engine here.)

> (i.e. would happen after the Jamfiles are read in, and
> even after the configure checks have been run, which - in my model -
> would mean that these steps could be represented by some synthetic
> intermediate targets (such as that "C-gen" step I invented for the
> purpose of the discussion).

The top level driver of Boost.Build is here:
https://github.com/boostorg/build/blob/develop/src/build-system.jam#L508

The three steps I listed above are here:
https://github.com/boostorg/build/blob/develop/src/build-system.jam#L705
https://github.com/boostorg/build/blob/develop/src/build-system.jam#L724
https://github.com/boostorg/build/blob/develop/src/build-system.jam#L974

>> Boost.Build makes no attempt to model configure
>> checks explicitly in the dependency graph, which
>> seems to be what you're trying to achieve.  In b2,
>> configure checks just take advantage of the ability
>> to inject arbitrary code into the target generation
>> phase.  The main advantages and disadvantages of
>> this approach are:
>> <snip>
>> - Running configure checks in parallel is difficult to impossible
> 
> How so ? At least the typical autoconf-style configure checks do little
> more than running compilation and linking steps. The main difference is
> that the results are fed back into the dependency graph.
> 

  Because the dependencies are not explicitly modeled,
but are rather a result of the ordering imposed by
executing code it's impossible to schedule the
tasks in any way other than running them as they
are encountered.

In Christ,
Steven Watanabe