Re: [Boost-build] prototyping alternative Boost.Build syntax

Subject: Re: [Boost-build] prototyping alternative Boost.Build syntax
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-11-04 19:08:41

AMDG

On 11/04/2016 04:42 PM, Stefan Seefeld wrote:
> On 04.11.2016 16:43, Steven Watanabe wrote:
>> 
>> On 11/04/2016 01:21 PM, Stefan Seefeld wrote:
>>> On 04.11.2016 11:18, Steven Watanabe wrote:
>>>> On 11/04/2016 07:29 AM, Stefan Seefeld wrote:
>>>>> Thus I have a few questions:
>>>>>
>>>>> * where in the code are target settings activated / deactivated so they
>>>>> are visible to actions ?
>>>> <snip>
>> The settings are applied here:
>> https://github.com/boostorg/build/blob/develop/src/engine/make1.c#L1087
>>
>> The call to the action is inside cmd_new:
>> https://github.com/boostorg/build/blob/develop/src/engine/make1.c#L1125
>>
>> which is defined here:
>> https://github.com/boostorg/build/blob/develop/src/engine/command.c#L61
> 
> Oh, I see. And now I understand why the command execution doesn't share
> an environment: All environment variables are represented as variables
> inside bjam ! It seems there is a lot of string copying going on. I
> wonder how much performance improvement can be gained by simply
> persisting the environment (and only overwriting the variables that
> actually change).
> 

  Copying strings is cheap.  The biggest cost
of pushsettings is in the name lookup.  Trying
to figure out what variables need to be changed
would be at least as costly as (and considerably
more complex than) simply resetting it ever time.
In addition, a significant fraction of on TARGET
variables are different for every target.  I've
never tried to optimize this particular area,
because the profiler hasn't shown it as significant.

In Christ,
Steven Watanabe