Mere moments ago, quoth I:
On 11/08/2015 06:35, Andrey Semashev wrote:
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?
One question is why Boost is trying to load the cross tools rather than the native x64 compiler.
While it's not unheard of to want to build 64-bit code from a 32-bit build machine, the vast majority of cases will be the reverse, so the native compilers should be preferred unless explicitly requested otherwise.
(Recent stats say that 92% of new Windows machines are 64-bit; older machines have a higher percentage of 32-bit but it's very likely that developers, at least, will have 64-bit machines by now.)
Ok, examining msvc.jam I think I've found the issue. It defaults to "x86_amd64" (cross compiler), and then swaps this to "amd64" (native compiler) if the environment variable PROCESSOR_ARCHITECTURE is set to AMD64. However this will only be the case if the process executing the jam file is also 64-bit. A 32-bit process running under WOW64 will see "x86" for that environment variable, just like it would on 32-bit Windows. So, either Boost.Build itself needs to be a 64-bit process, or it needs to be more clever at detecting a 64-bit architecture even as a 32-bit process. The simplest way of doing the latter is to read PROCESSOR_ARCHITEW6432, which will be unset for native 32 or 64-bit and set to AMD64 on 32-bit WOW64. (ie. the jamfile should assume native 64-bit if either of PROCESSOR_ARCHITECTURE or PROCESSOR_ARCHITEW6432 are set to AMD64.)