On Tue, Jul 28, 2015 at 9:49 AM, Vladimir Prus
Hi Tom,
On 28-Jul-15 3:44 AM, Tom Kent wrote:
Looking at the boost-build code, this batch file is created in build/src/tools/msvc.jam:744. This file will create the temp file in question by grabbing the output of a run of the visual studio environment setup routine (i.e. C:\Program Files (x86)\Microsoft Visual Studio 14.0\vc\vcvarsall.bat amd64). However, for the msvc-14.0 / address-model=64 case, it seems that it is combining the 32 bit and 64 bit variables into one causing this issue (and other variables that shouldn't be set by the amd64 run, such as FrameworkVersion32 and FrameworkVersion64...just running the above command only sets FrameworkVersion64).
Is it possible that build is running the 32 bit variable file, then running the 64 bit instance?
local original-vars = [ SPLIT_BY_CHARACTERS [ SHELL set ] : "\n" ] ; local new-vars = [ SPLIT_BY_CHARACTERS [ SHELL "$(setup-script) $(setup-options)>nul && set" ] : "\n" ] ; local diff-vars = [ set.difference $(new-vars) : $(original-vars) ] ;
So we should be capturing the changes that the particular setup script does to environment; it's not obvious why this would start to fail with VS 14 - adding
ECHO $(diff-vars) ;
after the above lines might be illuminating. I'm installing VS 14 now, but it might take a day till I get to debug.
I have tried to add this echo and indeed it outputs the broken Path already. Also, I tried to print %PATH% from the console (VS2015 x86 x64 Cross Tools Command Prompt) and it also has the %DevEnvDir% path first there. I inspected the vcvarsx86_amd64.bat script which sets up the environment and I can see that in line 62 it indeed inserts %DevEnvDir% before the paths to the compilers, so we have our culprit. The question is what do we do about it?