Host tool isn't targeting x86 if the targeting platform is ARM

OK I think now I found the right fix. When we are trying to generate host tools, configure.cmd creates a new instance with vcvarsall.bat targetting x86. HOWEVER, the CMake generator is still "Visual Studio XX ARM" which is causing problem.

Therefore I introduced a new variable CMAKE_GENERATOR_HOST which is pointing to the correct generator if %ARCH% == ARM. Might be a good idea to set this variable whenever the targeting platform is different from the host platform, however we just don't have that many platforms for now...

Related Issues:

1. The compiler check of CMake will fail because Microsoft disable ARM desktop application building.
The easiest fix: Goto "C:\Users\<YOUR USERNAME>\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.ARM.user.props" and add the following lines between <Project> and </Project> tags:
<PropertyGroup>
<WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport>
</PropertyGroup>

A fix from CMake side is not in the release 3.0.2: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=60383cc9a0fbd6d31253baa3ae2326aef447dcdb

2. Since the way configure.cmd starts a new instance by "start /I" and "/I" option will trash any changes in the environment variable. However vcvarsall.cmd doesn't include the path to CMake. Therefore if one doesn't want to add CMake's directory to global PATH variable, you have to use a batch file to do the trick:

@echo off
set path=d:\rosbe\bin;%path%
call "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86_arm
call cmd /c configure.cmd VSSolution
pause

Set PATH in a cmd window and then call configure.cmd will result in CMake cannot be found. Using SETLOCAL and ENDLOCAL might help to solve this issue, though.