VS backend has serious cross-compiling issues

[jenatali]

Describe the bug
When setting up cross-compiling, you're supposed to use host_machine to indicate what will be running the resulting binaries, and target_machine if you're building a compiler which might target a different machine. The VS2010 backend uses target_machine to populate the .vcxproj file's architecture, not host_machine.

What's worse is that the compiler binary that was pointed to during the VS solution generation step is completely ignored. So, if you just specify cl.exe as the compiler, then as long as there's any cl.exe in your path, that's what the generation step will use for running all of its tests. Then, after the project is created and you load it in VS, the target_machine you used ends up selecting which actual compiler will be used.

To Reproduce
Attempt to cross-compile with --backend=vs2019 and a --cross-file pointing to something that looks like:

[host_machine]
system = 'windows'
cpu_family = 'aarch64'
cpu = 'aarch64'
endian = 'little'

[binaries]
c = 'cl'
cpp = 'cl'
c_ld = 'link'
cpp_ld = 'link'
cmake = 'cmake'
pkgconfig = 'pkg-config'

Expected behavior
Some form of error, because the cl.exe that gets invoked identifies itself as:

C++ compiler for the host machine: cl (msvc 19.28.29913 "Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29913 for x64")

Which is wrong when the host_machine in the cross file is supposed to be arm64/aarch64.

system parameters

• Is this a cross build or just a plain native build (for the same computer)?: Yes
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.): Windows 10
• what Python version are you using e.g. 3.8.0: 3.8.2
• what meson --version: 0.57.999
• what ninja --version if it's a Ninja build: N/A

[jenatali]

Some more details on why this is going to be nearly impossible to actually fix: Meson currently relies on the user to set up the environment for cl.exe before invoking Meson (i.e. run VSDevCmd.bat). This embeds paths to the build tools (cl.exe, link.exe) in PATH, paths to the SDK headers in INCLUDE, and critically also embeds paths to the SDK libraries in LIB.

If you have a project which actually needs to use both the native and cross compilers, this is impossible: If you set up a native VSDevCmd prompt, then the cross-compiler will fail to link any libraries, because LIB has the native libraries path, and similarly if you set up a cross VSDevCmd prompt, then the native compiler will fail to link against any libraries.

[dcbaker]

Just to add details here. We (Meson) really needs to have a way to load these "compiler setup scripts", probably through the machine file, which is an oft requested feature anywy.