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.
I'm not sure I use any non-target-specific variables in my own usage
of bjam. So unless the whole `make1cmd` business is querying the
variables to build the commands from the module settings, I assume I
could get rid of all the settings swapping and only access
`target->settings` directly. Right ?