As part of the First-Class Windows project, we’ve been assessing the state of OCaml on Windows. This document is a summary of our investigation, including our consultations with individuals involved in Windows-related work.
The immediate call to action for you is to give us your inputs and thoughts, challenge it and help us make it better. You can do this directly on that document, or by quoting into this thread.
We’ll have a window of 8 weeks to allow for this to happen. After that we will move this into the OCaml Platform section of OCaml.org to use as a reference and keep it updated over time.
As someone who is mainly interested on having the libraries I distribute work well on Windows I have the following two needs:
Clarify what it means exactly to port to windows among the three possilibilites and perhaps an explanation of why this complexity is needed would be nice. I have long thought that what we need there is less choice. Choose one port, one depext mecanism and then we all promise to support it well. I would rather lean towards the msvc port since that’s what proper windows mean, and I suppose (?) that nowadays if you really need what cygwin brings you are better off using wsl.
Reliable instructions on how to get a cli prompt on a windows machine from a unix operating systems using any kind of vm technology (e.g. using the images here) with a properly configured OCaml environment, which means: git and opam installed and properly working C dexpexts and internet connection.
If you are not primarily developing on windows most OCaml software readily ports to windows. However when it’s time to tweak builds when C is involved there’s usually a painful back and forth with windows users which would often be quicker to investigate myself directly. But setting up a windows environment usually gets in the way, I’d like that to be abstracted away :–)
Thanks @dbuenzli for hitting the nail on the head.
My feeling is that offering Cygwin as a viable environment for OCaml development (and the default one, at that!) is misguided. Cygwin should be considered an implementation detail of the compiler build system only. I understand that this is done because many OPAM packages assume a Unix-like environment for their build, but still I think that sooner or later we will have to swallow that pill anyway… For one, Windows binaries produced using Cygwin are basically undistributable (users need to install Cygwin to run them); and the Cygwin emulation layer is itself a never-ending source of issues to begin with.
Just as a note for people reading this, because i think this might be confusing: This comment is about the Cygwin port, which is rather unused as far as i know. The MSVC and MINGW ports (which still do need Cygwin or MSYS2 to build the compiler itself on native windows) can produce redistribuable binaries (with some caviats for either ports). For example the prebuilt binaries for opam are built using the MINGW port on top of Cygwin and produces static binaries that are executable on any windows machine without any prerequisite.
The native Windows build of opam (either from the published GitHub releases or from winget install OCaml.opam) provides the mingw-w64 port of OCaml by default and if Visual Studio is installed separately can also provide the MSVC port of OCaml.
At present (and for the foreseeable future), it’s not possible to build the Cygwin port of OCaml using native Windows opam (it’s technically cross-compilation). The only way to get the Cygwin port of OCaml in opam is to use the Cygwin port of opam (which is available through Cygwin’s opam package).
Thanks for the correction @dra27! The document seems to be wrong then:
Switch Initialisation Process
After running winget opam, the next step is to call opam init to initialise the installation and create your first global switch. At this point, opam needs to compile an OCaml compiler, which needs a C compiler, and it will ask you to pick between several options (Cygwin, mingw-w64, MSYS2, or MSVC) but defaults to Cygwin.
Does the MSVC port really require the full Visual Studio install? Iirc there is some command-line MSVC compiler toolchain distributed by Microsoft that can be programmatically installed?
There’s a command-line version of the MSVC compiler, but that’s still around a 2GB download. I don’t know if it’s so much more than cygwin + gcc + utils though.
I’m trying a new opam installation on native windows right now, and cygwin is a huge batch of file downloads. I see no reason to avoid MSVC in comparison. The first attempt to download cygwin failed with a message in the OCaml installation process. The second, after restarting the installation, stopped randomly with no feedback.
I think cygwin is a notoriously badly maintained project, and we have to try and avoid it. Ideally, the ocaml compiler could be a direct binary download for windows, and any remaining C compilation in the ecosystem would use MSVC.
There is Visual Studio Tools, yes (winget install Microsoft.VisualStudio.2022.BuildTools --override "--add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --passive"), but note that Visual Studio can also be installed “programmatically” and doesn’t have to be installed along with its GUI (however, there’s always a risk one might want the debugger…)
winget install OCaml.opam, followed by opam init.
Opam start to download cygwin (I chose an internally managed cygwin), and cygwin starts downloading until it… stops. After 2 attempts, I’m letting this rest. WSL works just fine for me for now, and clearly this isn’t ready.
cygwin is bad, and it’s always been bad. Every attempt I’ve made at using it for the past 25 years has made me sorry for putting in the effort (including when I used a Sony PSP toolchain to build homebrew programs). You bump into issues at every corner. IMO we don’t want to keep tying ourselves to cygwin long-term, or we’ll keep failing at delivering a good Windows experience.
“stops” - what does this mean? I’m always happy to investigate a bug report, but I do need one: How to Report Bugs Effectively
I agree with this (and indeed have devoted an inordinate amount of time working towards it). However, it’s not where we are now and, for what it’s worth, using MSVC still requires Cygwin (on the OCaml side) and will quickly use Cygwin even in the infrastructure (vcpkg, for example, uses Cygwin…)
Is there some path to using WSL2 with MSVC directly for native Windows binaries? The VSCode site seems to imply there is but I don’t have a Windows box at hand to see if the rsyncs mentioned are intrusive or not.
Not via that, I don’t think - I think that feature’s about being able to debug a Linux application from Visual Studio using WSL2.
Just as a summary of some of the possible future directions, it:
is possible to invoke MSVC from WSL and so use a WSL distro’s bash instead of Cygwin (some prototyping at Commits · dra27/ocaml · GitHub), but mostly it swaps one frying pan for another… it’s a lot faster, but it’s not simpler
Is there a list somewhere of exactly where that’s needed? I imagine these must be unixisms of some kind? I.e. it’s not cygwin per se but the cygwin dll?
So after trying a couple more times, I managed to get opam working on Windows, and I’m very impressed. It turns out the first failure was probably due to an old attempted installation. Erasing it fixed the issue.
I was able to install a whole bunch of packages. I even managed to get tsdl installed properly, but only after installing the latest SDL2 via vcpkg and playing around with some environment variables – the version installed by opam in cygwin automatically is from 2017 and caused both build and dynamic linking issues.
In general though, amazing job! I would recommend dropping the installation of packages via cygwin though, as detailed above, and just letting people install via vcpkg, or doing it internally with vcpkg if that’s possible.
