Following on from the teaser in ARM Windows installation as of today - #4 by dra27, if you’re lucky enough to have an ARM64 Windows machine, it’s just about possible to get a few opam packages installed and working it!
You’ll need Visual Studio 2022 (Community) with the following packages:
MSVC v143 - VS 2022 C++ ARM64/ARM64EC build tools (Latest)
MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest)
C++/CLI support for v143 build tools (Latest)
C++ Clang Compiler for Windows (18.1.8)
That’s not a typo: you need Clang and both the x64/x86 and ARM64 MSVC packages
Install Git for Windows as normal (winget install Git.Git
, etc.) and Cygwin (adding the make
and patch
packages - no compilers or libraries needed, it’s just to get the shell).
Clone my opam fork and check out branch windows-on-arm64. From a Cygwin bash terminal, cd
to that clone and run make cold
. After a little while, that should leave an ARM64 opam.exe
in the current directory which should be copied to a location which you then add to PATH
.
From Cmd/PowerShell, you can now run:
PS > opam init --bare
PS > opam switch create --empty windows-on-arm64
PS > opam pin add --yes ocaml-variants git+https://github.com/dra27/ocaml.git#windows-on-arm64
Dune needs a trivial pin (which I think may be more to do with a recent Windows SDK issue, than arm64-specific):
PS > opam pin add dune git+https://github.com/dra27/dune.git#windows-on-arm64
Unfortunately, it’s not quite enough to get opam’s dependencies installing through opam (dose3
failed for me, which is odd because it works with make cold
and topkg
was freezing, although that’s less surprising). But it’s kinda cool how much is working straightaway, and it certainly looks like we’ll have native Windows ARM64 support at some point in the future, therefore!
Aside from the usual “packages which don’t work properly” issue, there’re two glaring problems:
- It should be possible to install the x86 / x64 compilers, but at present this doesn’t work because the opam compiler packages need further tweaking[1]
- Only Clang-pretending-to-be-
cl
is supported at the moment - I can’t see any reason that Clang-pretending-to-be-gcc
shouldn’t be doable, but as we don’t presently support that for x64 either (and it necessarily needs MSYS2, rather than Cygwin), I haven’t disappeared down that rabbit hole yet[2]
I have no timeline for upstreaming any of this, but it’s all publicly pushed and welcome to anyone to extend to a mergeable state!