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:
> 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:
>>>> 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
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:
> The three steps I listed above are here:
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:
>>> - 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 ?
-- ...ich hab' noch einen Koffer in Berlin...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk