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-10-31 16:18:36

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.

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

In Christ,
Steven Watanabe