vcpkg_build_msbuild is broken if TRIPLET_SYSTEM_ARCH is different from x64

[traversaro]

On my machine (I did not double checked on a second machine at the moment) it seems that the vcpkg_build_msbuild command is broken for all triplets for which TRIPLET_SYSTEM_ARCH is different from x64 .
In particular it seems that the msbuild command is not found because the PATH contains the directories of Visual Studio tools only if TRIPLET_SYSTEM_ARCH is equal to x64 .
I checked this by adding a message(STATUS "PATH : $ENV{PATH}") debug print.

PATH for x64-uwp :

-- PATH : C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64;C:\windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\;C:\windows\system32;C:\windows;C:\windows\system32\Wbem;C:\windows\system32\WindowsPowerShell\v1.0\

PATH for x64-windows-static :

-- PATH : C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64;C:\windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\;C:\windows\system32;C:\windows;C:\windows\system32\Wbem;C:\windows\system32\WindowsPowerShell\v1.0\

PATH for arm-uwp :

-- PATH : C:\windows\system32;C:\windows;C:\windows\system32\Wbem;C:\windows\system32\WindowsPowerShell\v1.0\

PATH for x86-windows :

-- PATH : C:\windows\system32;C:\windows;C:\windows\system32\Wbem;C:\windows\system32\WindowsPowerShell\v1.0\

In theory the problem should be reproducible by tryng to build a port that uses vcpkg_build_msbuild for the x86-windows , for example with a vcpkg install box2d:x86-windows.

I wonder if this problem depends on something on my machine, because the chakracore port use vcpkg_build_msbuild as well, and it should be one of the few ports tested in the CI system described in #72 (comment) .

[alexkaratarakis]

1. e4c5ef6 changes the way we set the environment with vcvarsall.bat, so this might be a regression. Are you using the latest vcpkg?
2. For a triplet (like x86-windows) that is not working, try using:
   vcpkg env --debug --triplet x86-windows
   This will change the console to the environment vcpkg uses to do the builds (use exit to go back to your original environment). --debug will also display extra information, so we can see if something fails in this step*. If it works, use:
   path
   to display the PATH variable.

*I think this will probably fail in your machine, and hopefully we can get some info as to why.

[traversaro]

Installing ode and other ports vcpkg_build_msbuild seems to be working fine in a new vcpkg installation, so probably there was something wrong in my enviroment back when I opened the issue, or there was some issue in vcpkg that has been solved since then. I think we can close this issue now.