[ANN] Windows-friendly OCaml 4.12 distribution - Diskuv OCaml 0.1.0

I installed diskuv and did opam switch list-available. It responded with # No matches found. Does opam switch create not work? I am looking to try ocaml 5.0 on windows.

Use opam dkml init to create a 4.12.1 switch (use --help if needed). There is a walkthrough on Beyond Basics — Diskuv OCaml 0.4.0 documentation for how to use that.

opam switch create does work as long as you pick the right OCaml compiler, but a regular switch is not sufficient for packages with embedded Unix commands to work on Windows. opam dkml init handles the Unix bridging, the correct OCaml compilers and also the extra Windows Opam repositories for you.

OCaml 5.0? I haven’t even looked at 5.0 yet, and wasn’t planning on adding it until the 5.0 compiler and several widely used packages were ready on the MinGW flavor of Windows. That might be a while. Why wait? Because the regular Diskuv installer is prioritizing everything-should-work-out-of-the-box-on-Windows. If that timeline conflicts with something you are working on (ex. you maintain a widely used package or tool) please give feedback.

1 Like

I tried it today, it mostly works, thanks!
opam install ocaml-lsp-server also works, but when I format a file in vscode, I got an error:

ocamlformat: option `--profile': invalid value `'conventional'', expected one
             of `conventional', `default', `compact', `sparse', `ocamlformat'
             or `janestreet'
Usage: ocamlformat [OPTION]... [SRC]...
Try `ocamlformat --help' for more information.

The other feedback is that it took too long, almost 3 hours to have it installed. It is hard to convince people to give it a try unless he/she is already sold on ocaml.


I also tried opam install ppx_jane, which gave me such an error:

PS C:\Users\IDEA\git\hello> opam install ppx_jane      
[NOTE] External dependency handling not supported for
       OS family 'windows'.
       You can disable this check using 'opam option   
       --global depext=false'
[ERROR] Package conflict!
  * Missing dependency:
    - variantslib >= v0.14
    not available because the package is pinned to     
      version 109.15.02

No solution found, exiting
1 Like

I agree. It needs to transition to precompiled executables, at least for the compiler and such.

Do I understand it right, this mean that you can statically link OCaml binaries into native Windows application if you build using CLANG64? If so, this is really cool.

This is the first time I hear about using clang on Windows with OCaml. As I understand, since clang has similar interface to GCC it is mostly straightforward to swap it for MinGW GCC in the MinGW port? Does anyone have experience with such setup? Compilation speed and performance? I remember my colleague Niels G. W. Serup looked at MinGW GCC vs. MSVC on Windows and OCaml bootstrap was slightly slower with GCC, which is not a huge deal. I wonder, how is it with clang… Also, I think I heard from @nojb that MinGW GCC port is a bit slower for floating point math functions, since MSVC is apparently better at implementing them as intrinsics. Wonder how is it with clang is here, again…

One thing I found as I was digging deeper is that there are two different variants of CLANG64 on Windows: 1) the version available from MSYS2 that uses the MinGW headers and 2) the version available from Visual Studio that uses the Windows SDK. So I don’t think CLANG64 in MSYS2 will be ABI compatible as I was initially led to believe.

Yes, if anyone has more information that would be useful.

The goal of CLANG64 on Windows is to provide a cl.exe front-end to the clang compiler. So yes it would help in an incremental swapping process to add Windows compatibility to a Unix-only OCaml package. That is:

  1. Starting from GCC + Linux
  2. Port your C headers to MinGW. Now you have GCC + MinGW using either Cygwin or MSYS2.
  3. Port the build logic (how to specify include directories, compiler warnings, etc.) to cl.exe. Now you have cl.exe + MinGW using CLANG64 + MSYS2.
  4. Port your C headers to Windows SDK. Now you have cl.exe + Windows SDK using either CLANG64 + WinSDK, or MSVC. And you have to install the Windows SDK, but you get real ABI compatibility.

(Of course you can skip some of those steps, or even stop early.)
I’d like to know if anyone would benefit from step 3.