question(s) about bjam code IV

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

question(s) about bjam code IV

Boost - Build mailing list

Hi Steven,

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.

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 ?

Thanks,


Stefan
-- 

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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: question(s) about bjam code IV

Boost - Build mailing list
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.

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

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: question(s) about bjam code IV

Boost - Build mailing list
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...
    

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: question(s) about bjam code IV

Boost - Build mailing list
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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: question(s) about bjam code IV

Boost - Build mailing list
On 27.10.2017 16:17, Steven Watanabe via Boost-build wrote:

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 ?

Thanks,

Stefan
-- 

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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build