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:27:55

Sorry, all of this would make more sense with the actual link:
https://github.com/stefanseefeld/faber/wiki/Workflow

On 04.08.2017 12:09, Stefan Seefeld wrote:
> 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...