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-09-25 19:26:34

Hi Steven,

I hope you don't mind me following up on this long and ongoing
discussion. It's really helpful for me to understand not only the
existing code but also the underlying rationale of the design.

On 04.08.2017 00:41, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 08/03/2017 09:26 PM, Stefan Seefeld via Boost-build wrote:
>> On 03.08.2017 20:37, Steven Watanabe via Boost-build wrote:
>>> On 08/03/2017 03:57 PM, Stefan Seefeld via Boost-build wrote:
>>>> Consider again my earlier example, where the target "C" depends on some
>>>> config checks "A" and "B", during the update of which some properties
>>>> will be set that are used to build C.
>>>> I think the spelling was
>>>>
>>>> exe C : C.cpp : [ check-target-builds B : <use>B ] ;
>>>>
>>>> So, let's assume that one of the usage requirements of "B" affects the
>>>> choice of the toolset, or some other essential property that influences
>>>> the qualified filename .../C.exe.
>>>   That's not allowed.  Only free features can be
>>> used in usage-requirements.  The appending
>>> behavior of free features is necessary.  If
>>> usage requirements can override properties, then
>>> it's essentially impossible to maintain consistency.
>> Can you give an example of a scenario giving rise to inconsistency,
>> would this be allowed ?
>>
>   There's no clear priority for usage-requirements
> from two different dependencies.  As a result,
> if two dependencies have contradictory usage
> requirements, it can only be a hard error, as
> neither one can override the other. 
Yeah, I agree. But in the absence of any such contradictions, I'm still
not convinced of the need to restrict features to be applied "late" to
have to be "free".
(I'm not trying to be difficult. Rather, I'd like to establish a minimal
set of working rules, in the hopes to make the overall interface
simpler. For users having to remember that only certain features may be
set as "usage requirements" seems more complex than necessary.)

>  Propagated
> features are even more problematic because they
> are supposed to be passed on to dependencies.
> Therefore propagated usage requirements would
> have to spread out to the entire dependency graph,
> which is completely impractical.

OK. As I mentioned, I have eliminated the whole concept of "feature
propagation", also in an effort to simplify the build workflow. It of
course remains possible to build multiple "variants" at once, but they
don't propagate any features up the dependency chain, rather than
explicitly depending on concrete targets. (Read: there are no
"meta-targets" and "virtual targets" in my design.)

Now I'm still struggling with the internal workflow in bjam:

make0() is used to bind all targets and determine a target's "fate",
which is then later used in make1() to determine what to do. If I want
to remove the restriction on "free" features above, it means that a
target's boundname (filename) may be set later in the process (after
prerequisite targets are updated). Therefore I need to either move some
of the logic from make0() into make1() (and its subcalls), or I need to
repeat it.

Can you advise me whether that's possible at all, or whether that would
create logical issues in the workflow ? Notably, if I bind a new
(file-)name to a target sometime in a make1x() call, I'd need to
(re-)run the logic from make0, steps 4g and 4h. Would that be possible
at all ? (Right now no make0() call happens once the first make1()
invocation has started.)

Thanks !

        Stefan

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