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

Subject: Re: [Boost-build] question(s) about bjam code IV
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-10-27 20:17:56

AMDG

On 10/27/2017 12:46 PM, Stefan Seefeld via Boost-build wrote:
> On 27.10.2017 13:26, Steven Watanabe via Boost-build wrote:
>> 
>> 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 ?

  To be completely consistent, you should call popsettings before
and pushsettings after.  This should pair with the pushsettings and
popsettings surrounding your code.  It doesn't actually affect the
result, though, since pushsettings and popsettings are identical.

>>> 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.
> 

  It isn't necessary per se.  It's an implementation
artifact.  pushsettings and popsettings are both
implemented essentially as
  swap(target specific variables, module variables)
In short, after calling pushsettings, target->settings
temporarily holds the old values that are restored
by popsettings.  This works as long as the code in
between pushsettings and popsettings never tries to
access the target specific variables (which is the
case in the existing code, but apparently not for you).
The correct solution is to add copysettings and then push/pop
the copy instead of using target->settings directly.

In Christ,
Steven Watanabe