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-04 16:09:09

Hi Steven,

On 03.08.2017 23:26, Stefan Seefeld wrote:
> On 03.08.2017 20:37, Steven Watanabe via Boost-build wrote:
>
>>> 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.
> 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` ?)

I have outlined the workflow of such a build with three different
snapshots of the dependency graph:
* one as it is encoded in the fabscript,
* one has faber would see it once it has completed parsing the fabscript
(and any other input, including command-line options), and
* one some time later, once the dependency graph related to the "C"
artefact has been expanded by the assembly.

This corresponds to my own (mental) model, as well as how it is
implemented in faber (some of which is still work in progress).
So now I would like to understand whether you see any design flaws (or
bugs) in this approach, and how that maps to b2's model.

In particular, I don't see any fundamental problems in letting almost
arbitrary features (or "usage requirements") be added in the process. Of
course, if incompatible values are combined, an error needs to be raised.

(Note that I found a simple way to run the config checks without
requiring synchronization: the outcome of an action is fed back into the
associated artefact, from which it is available when the next action is
performed. So the only call to "update_now" is the global one performed
to update the goals from the command line...)

        Stefan

PS: There are a few terminology changes: I use "artefact" where b2 uses
"target", and "assembly" where b2 uses "generators". Furthermore,
"feature sets" replace "property sets". I hope that doesn't distract
from the overall similarity of the models.

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