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

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-05 22:27:48

On 08/05/2017 04:15 PM, Steven Watanabe via Boost-build wrote:
> 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.)

Ah, may be that's part of my misunderstanding. So let me outline my
understanding of this. Please correct me as appropriate:

The engine is a scheduler for actions needed to update targets. So it
has a representation of targets to indicate whether they need updating,
are up to date, or are somewhere in between. Actions are written in Jam,
and are parsed into some IR by a Jam parser when the Jamfile is read in.
At some point these actions are translated (by the Jam interpreter) into
a sequence of commands that are run sequentially (by the scheduler).

(What I still don't quite understand is the relationship between rules
and actions.)

So, with that being said, I imagined the lowering being done as part of
some "action" to update a (synthetic) target (see my own model for doing
this). Why ? Because it hasn't been done *during* the parsing of the
Jamfile, so I assumed it was delayed, until after the config targets
were updated (at which point the property set was known).

>> (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

Ah, so it now looks like this happens after the Jamfile has been parsed,
but before the engine is "started", and thus, before the config checks
are run. (Thus the question: how can the config check results be used,
if the lowering happens before they are known ?)

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

Ah. Yeah, that is a problem. But I suppose there would be ways to
translate the "<use>A" expression into an additional dependency to A,
thus forcing a particular order of execution ?

        Stefan

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