mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.56k stars 1.61k forks source link

VS backend has serious cross-compiling issues #8554

Open jenatali opened 3 years ago

jenatali commented 3 years ago

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

jenatali commented 3 years ago

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 commented 3 years ago

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.