Re: [Boost-build] question(s) about bjam code IV

Subject: Re: [Boost-build] question(s) about bjam code IV
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-10-27 18:46:50

On 27.10.2017 13:26, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 10/26/2017 09:26 PM, Stefan Seefeld via Boost-build wrote:
>> now I'm looking into target-specific variables. I have added a few callbacks to 
>> bjam to be able to set and query target-specific variables at different stages 
>> of the build.
>>
>> I'm a bit puzzled right now, as the variables I set earlier are no longer 
>> visible at some later point. It seems this is related to the various 
>> "pushsettings" / "popsettings" etc. invocations that happen throughout the bjam 
>> code.
>>
>   This could be because the code is cheating slightly.
> pushsettings moves the target variables into the
> module (instead of copying).  We can get away with
> this because the code between pushsettings and popsettings
> never accesses the target variables.  You might need
> to make a copy with copysettings.

I actually fixed my issue by wrapping the variable access with
`pushsettings(root_module(), target->settings)` and
`popsettings(root_module(), target->settings)`, though I admit I still
don't quite understand why that's needed. Why can't `target->settings`
invariably point to the target-specific variables ? Is there any point
in time where that's not appropriate ?
>> Could you please briefly explain what those do, and why they are needed ? I'm 
>> not using modules, i.e. everything I do happens in the context of the "root 
>> module". Do I still need to push and pop settings ?
>>
> Any place with push and pop settings in make/make1 is
> because the code needs to access a target local variable.
> There are several special variables (SEARCH, LOCATE, HDRSCAN,
> __ACTION_RULE__, etc) that can be target specific, in
> addition to any variables named in the ACTION.

Hmm, so whenever a "global" variable may be overridden by a
target-specific variable, I can see that some global (or
module-specific) dictionary needs to be updated from the current
target's variables. What I don't see is why the target->settings
themselves need to change.

Thanks,

Stefan

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