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

Subject: Re: [Boost-build] prototyping alternative Boost.Build syntax
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-31 16:31:47

On 31.10.2016 16:18, Steven Watanabe wrote:
> AMDG
>
> On 10/31/2016 01:56 PM, Stefan Seefeld wrote:
>> On 31.10.2016 12:29, Steven Watanabe wrote:
>>>> When building with MSVC, somewhere in the process one of these
>>>> "vcvars32.bat" scripts is read in to set up environment variables that
>>>> are later used during the invocation of "cl.exe" etc. As I suppose that
>>>> script isn't read in on each invocation of an action that calls one of
>>>> the MSVC tools, I suppose some form of environment sharing has to be used.
>>>> Am I wrong ?
>>>>
>>>   vcvars32.bat is called on every invocation of
>>> the compiler.  There is no environment sharing.
>>
>> Is there a way for me to convince you (or someone else maintaining the
>> bjam C code) to add support for environment sharing ? I understand that
>> this may not be relevant for the current version of Boost.Build (which
>> works around the current limitation), but for any future work this would
>> be very useful ! (The bjam_define_action() and bjam_call() functions
>> could take an optional extra argument that would be the environment to
>> share. This would make it much easier to design the Python layer...)
>>
>   Anything that's added to the existing system
> needs to work with Jam as well.  Adding an
> argument to bjam_call isn't going to work
> because the corresponding Jam syntax simply
> doesn't allow for it.  In principle, setting
> environmental variables is common enough
> that having built-in support would be
> useful.  The main problem is designing the
> interface for it.

I understand. I don't quite understand why adding an argument to
bjam_call() (or adding a new function "bjam_call_with_env()") wouldn't
work, though. The logic would be simply that by default no environment
is set, so the "execvp()" function continues to be used to invoke the
command.
But, whenever an environment is present, "execvpe()" would be called
instead. (The equivalent Windows code right now passes down NULL for
environment pointer, so this change looks like it could be easily
integrated there as well.)
>>> (Actually, Boost.Build writes its own version
>>> of vcvars32.bat because on some version of msvc,
>>> the provided vcvars32.bat is quite slow.  However,
>>> for your purposes, this detail doesn't really matter.
>>> The point is that the environment must be set
>>> up from scratch every time.)
>> SCons introduces the notion of a "construction environment"
>> (http://scons.org/doc/HTML/scons-user.html#sect-construction-environments),
>> which I find quite elegant, and having the ability to define something
>> like that in bb3 would be very useful.
>>
>   As far as I can make out, a construction environment
> has nothing to do with environmental variables.  It
> looks like it's basically like a property-set in Boost.Build.
> It does have a field for environment variables, but
> the data structure isn't easily representable in Jam.

Indeed, a construction environment in SCons is more than just a set of
environment variables, but it does contain one, and all commands
executed from within that environment will see those variables. Thus,
vcvars32.bat wouldn't have to be executed with each command execution...

You are also right that it is somewhat similar to a property-set. I'm
not suggesting "construction environments" to replace property-sets. I
think there is a place for both. And the fact that right now all
environment variables have to be passed down explicitly and individually
with each command invocation demonstrates that there is room for
improvement.

Thanks,
        Stefan

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