Cross compile on Windows with Visual Studio for ARM64

[lelegard]

Hi,

Considering an existing third-party project which is managed by meson, how would you build that project on a Windows Intel host using Visual Studio for an ARM64 target?

This looks like a simple question. In fact, when using other build tools such as msbuild or cmake, it is as simple as msbuild /property:Platform=ARM64 or cmake -A ARM64.

However, using meson, it seems extremely complicated. This use case becomes of course relatively common and the question has been asked many times online. Surprisingly, I have found zero clear and complete answer. Just hypotheses, tests, various partially described dirty hacks, quite often applicable to a single project. Nothing specific. Nothing reliable. Nothing that works in my case.

The solution should be simple. Windows systems run on 3 majors architectures: Win32/x86, Win64/x64, ARM64. Using Visual Studio and the tool suite which comes with it, you can build from any host platform to any target platform. In some environments, we call that cross-compilation and it needs some specific configuration and setup. In the Windows environment, it's just compilation, all targets are equal, no specific environment, just specify a target name "Win32", "x64", "ARM64".

Quite often, in the numerous posts I have read, the answer to the question is "use a cross file". Alright, but what would be its content? No clue. It's simpler to say "use that" than giving precise details. I don't even see why we should describe a cross-build environment. Remember that, in the context of Visual Studio, this is only one single name in a project file, one single name in a command line parameter.

I understand that a cross file can be needed when you use non-standard tools, when you build to some specific embedded device, using a proprietary SDK for instance. But here, Visual Studio is an integrated environment where there is no difference between targets, native or cross. All the dirty configuration of using which and what is already integrated inside Visual Studio. Why would we need to reinvent the wheel in a meson cross file?

FYI, my context is the following. I develop and maintain an open source project named TSDuck which works on Linux, macOS, BSD, and Windows. This project uses a couple of third-party libraries which need to be rebuilt on Windows, for all target architectures (on Linux and macOS, all distros already include them). One library is built with cmake, the other one with meson. I am familiar with none of these two, even less with meson.

Based on various online information, I tried several solutions without luck. So far, with only Win32/x86 and Win64/x64, using the environment variables from the various VS-supplied scripts such as vcvarsamd64_x86.bat and the like was sufficient. However, it no longer works when you add ARM64. Using the scripts alone, outside a meson project, you can build a x86 or ARM64 project. Using meson, on the other hand, building for x86 works but building for ARM64 fails. This method is probably a hack, so I am not surprised it works in some cases only.

Could we use this discussion thread to build, with the help of meson experts, a definitive and complete response to the simple question: how to build a meson project for any other target on Windows using Visual Studio?

[Molier]

I have tried and failed to have a reliable stack on my machine to build linux packages in and for my arm64 laptop, but the blocker has consistently been meson , the same with trying to compile and build some other stuff fe vlc. i have tried with msys2 arm64 stack , tried with the native visual studio arm64 stck. no success so far
so very interested as well

[lelegard]

Hi @Molier

As you can see from the lack of answers, meson people are not interested in the subject.

My original interest was to rebuild the librist project on Windows for multiple targets. The only solution I have found so far is:

• Loop on all target architectures.
• Run meson setup without any architecture specification, as if it was a native build.
• If the target architecture is not the host architecture, modify all *.sln and *.vcxproj files to update the target architecture and other specific details.
• Run MSBuild on the updated project files.

This is implemented in the following script:

https://github.com/tsduck/rist-installer/blob/7f61087ed1d046542981c6ef64e8f7b883f3be3b/win/build.ps1#L296-L312

This is dirty, hacky, non-portable, maybe not fully reliable, completely contradictory with the meson paradigm of hiding all platform-specific details for a transparent build. However, when you have to build a third-party project which is implemented using meson and meson does not care about your platform, there is no other choice.

[bonzini]

Visual Studio is an integrated environment where there is no difference between targets, native or cross. All the dirty configuration of using which and what is already integrated inside Visual Studio. Why would we need to reinvent the wheel in a meson cross file?

Because build and host machines can and will have different results for libraries, headers etc.

Though I suppose meson could be taught to build the binaries section of the cross file autonomously when using the VS backend. Would that work for you?

[lelegard]

Because build and host machines can and will have different results for libraries, headers etc.

Of course, the libraries and headers are different. But they are all here, within Visual Studio environment (unless you did a partial installation of it, excluding specific targets). There are only a few specific values to generate in the VS project files, as demonstrated in the above-mentioned script.

Though I suppose meson could be taught to build the binaries section of the cross file autonomously when using the VS backend. Would that work for you?

I don't know meson and I cannot tell how this should be implemented. I can only specify the need, which is "build on Windows, for Windows, using Visual Studio, targeting any of x86, x64, Arm64, regardless of the native architecture".

This needs is natively addressed by Visual Studio. Therefore, the extra layer of meson is not an added value (it is even a "removed value" in that case).

The concept of "cross file" in meson seems designed to support custom cross-compilation environments on Linux. It seems overkill for Visual Studio "cross compilation". There is no different environments, just different parameters. I would add that the current meson way of calling .bat files inside .vcxproj file is incorrect (or at least overkill). The Visual Studio environment does not need any setup at all to cross compile. Only specify the right "platform" name in the .vcxproj and .sln files, one of:

<Platform>Win32</Platform>
<Platform>x64</Platform>
<Platform>ARM64</Platform>

That's all. Nothing more, not .bat, no nothing.

You can even have a single set of project files and build using MSBuild /property:Platform=XXX.

So, the solution of our problem is not to add more complexity to meson to handle the case. It is to remove the current unnecessary complexity in the meson way of handling Visual Studio. Then, the solution will become trivial.

Note: I am not a "Windows developer". I am a UNIX developer (Linux, macOS). Building on Windows is always a pain, but it can be managed by experience. What drives me crazy is that meson currently adds more pain to existing pain on Windows 😃