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,

-- 

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