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.
