Windows on ARM fixes #427
Open
Windows on ARM fixes #427
+1,670
−487
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Due to the differences in compilers and Windows 11 not differentiating between x64 and arm64 installation paths in Program Files, it looks like we'll need a separate installer for native ARM builds.
MSVC (including ClangCL) and GCC (including standard Clang) are not C++ compatible, and this has caused no end of headaches on ostensibly 'simple' matters of compiling plugins for x86(-64). Windows on ARM is still a relatively niche target, there has not yet been a truly fleshed-out release of AviSynth+ for it, so let's avoid repeating this mistake. There is no legacy cache of native ARM plugins to get messed up by this, and there is the upside of any future architecture choices not being hampered by requiring any compatibility with MSVC. Windows on ARM builds are therefore to be built with MinGW, and the MSVC codepaths are fused off for any non-x86(-64) arch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some fixes are to get certain things to build (Shibatch) or skip building (VDubFilter), some are revising the documentation, and the most important one: explicitly blocking the use of MSVC to build ARM binaries. I'm tired of having to reiterate why person X's attempt at loading plugin Y failed on x86(-64) because they built it with MSys2 and the plugin is a C++ plugin.
Windows on ARM is different, though; it's still a relatively niche platform and we have never actually done a proper release for it (just an experimental build or two a few versions back that was just an archive, not an installer), much less one that's allowed an entrenched plugin ecosystem to arise around using MSVC on there, too. In a lot of cases of previously-unported plugins, supporting Windows on ARM is going to require plugin devs to modify their code to section off the x86 SIMD, so if they have to go to that length, switching to llvm-mingw or GCC (once support for Windows on ARM lands in a stable GCC release) as the compiler is not that much more difficult. Especially considering the fact that WSL2 is right there on modern Windows 10 and 11, and the Windows on ARM target computers are all officially running Windows 11 anyway¹ (Windows 10 on ARM does exist, but the mass-market products with it were underpowered netbooks or IoT devices, and people beating it with a hammer until it would run on a Raspberry Pi...which is a painful experience).
¹the Snapdragon [X|X Plus|X Elite] laptops, all of which have the Copilot+ branding, as those chips have competitive performance and make Windows on ARM actually worth using.
The way the check happens is that it allows MSVC (or ClangCL) to work if it detects that it's being built for an x86 or x64 target. If it detects anything else, it stops the configuration dead and tells the user to use MinGW (which would be ARM64, but if Microsoft does anything weird in the future and adds other arches like RISC-V, we're already ready for it). There's also a block in
avs/config.hso that plugins including the header will fail to build if it's targetting the wrong combination of compiler, OS, and architecture.Because only MinGW plugins can be built for ARM, the workaround for GCC core builds having their own plugin directory/registry entry becomes irrelevant, so again, that registry entry/directory is only enabled for searching on X86.
The x86(-64) external deps guide now also includes instructions to install pkgconf without the user having to piggyback MSys2's environment.
The InnoSetup script for ARM probably needs some trimming down, but just getting it in here is a first step.