Subject: Re: [Boost-build] prototyping alternative Boost.Build syntax
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-10-31 16:18:36
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"
> 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.