Boost logo

Boost-Build :

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2019-07-15 01:09:17


On 7/14/19 6:35 PM, Edward Diener via Boost-build wrote:
> On 7/14/2019 6:10 PM, Steven Watanabe via Boost-build wrote:
>> On 7/14/19 3:16 AM, Edward Diener via Boost-build wrote:
>>> <snip> I am pretty sure that having a single msvc-setup.bat for
>>> all versions of Intel C++ on Windows and vc++ compatibility for any
>>> given version can not be correct design, <snip>
>> You're correct.  The issue is here:
>> <snip>
> I have discovered that I can force the msvc-setup.bat for intel-win to
> be regenerated for each b2 invocation when specifying an intel toolset
> with:
> <snip>
> if $(rewrite-setupscript) = always
> {
>     toolset.flags intel-win .REWRITE-SETUP $(cpu-conditions) : true ;
> }
> toolset.flags intel-win .SETUP-SCRIPT $(cpu-conditions) : $(setup) ;
> toolset.flags intel-win .SETUP-OPTIONS $(cpu-conditions) : "$(c)
> $(iclvars_vs_arg)" ;

There's one more variable, which is .SETUP. If you set this,
then it will be used directly, and msvc.jam will not attempt
to make its own setup scripts. This is specifically to allow
users to work around any problems with the generated setup

> This allows me to test different versions of Intel C++ on Windows, each
> having a compatibility with different versions of vc++ by specifying the
> '<rewrite-setup-scripts>always' option in each toolset definition. In
> the current Boost Build intel-win code the msvc-setup.bat once generated
> is never replaced. Of course even my temporary fix will not solve the
> problem of running b2 with different Intel Window toolsets at the "same
> time" because the single msvc-setup.bat will be overwritten by each
> intel toolset used. The real culprit is that the single msvc-setup.bat
> for all versions of Intel C++ for Windows and all possible vc++
> compatibilities for each version is inadequate.
> The right solution is to have different msvc-setup.bat files for intel
> generated in subdirectories for each version of Intel C++ for Windows/
> each vc++ compatibility. I just do not know how to tell the
> 'set-setup-command' where to place the msvc-setup.bat. I do notice that
> for msvc there are separate subdirectories for each msvc-setup.bat, so
> evidently my solution seems somehow doable.

A general fix would be to add all the subfeatures of
the current toolset instead of hard-coding the msvc
version on the line that I pointed out.

> Did anybody even realize that the current change to provide our own
> setup scripts, combined with the single msvc-setup.bat location for the
> intel-win toolset, destroys the ability for end-users to use more than a
> single Intel C++ for Window implementation/vc++ compatibility with Boost
> Build as it currently exists ?

I certainly wasn't aware that intel-win uses a single
location until you brought this up. I'm pretty sure that
I'm the one who broke this, when I moved the setup
scripts from %TEMP% to the build directory, so I doubt
anyone else noticed, either.

> Or was it actually known but just deemed
> too small a situation, given how few users probably use Intel C++ for
> Windows in the first place, to matter that much ? I am not trying to
> criticize anybody but I am just curious if anybody knew about this
> before I discovered it through attempting to test Intel C++ on Windows
> against some Boost libraries.

In Christ,
Steven Watanabe

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at