Preferred OCaml Windows environments [mainly for Continuous Integration]

build
windows

#1

Dear all,

apologies in advance if this question has been asked.

We are in the process of setting Continuous Integration for the WIndows build of OCaml projects that use stubs and C libraries.

To the best of our knowledge, there are several choices on how to setup the build environment; a good example is Coq, where we have two different windows builds [one using opam+Azure and the other using a custom package installer+gitlab]

My question is, what should be the preferred “OCaml Windows setup” our CI projects should use? How should we install C libraries such as openssl or gtk?

Best regards,
Emilio


#2

I’m looking at this at the moment for opam-repository and dune CI as well, with largely the same questions.

@dra27 has got some early automation going for the base Windows images, but I still have no sense of how the depexts “should” work. It would be useful to know if any strong contenders emerge for regular Windows users for making external dependencies available to CI and build systems, other than Cygwin.


#3

I’ve only enabled cygwin’s repo for https://github.com/ocaml/ocaml-ci-scripts. If your package depends on a public conf-package (e.g. conf-openssl or conf-gtk3), the dependencies will be installed automatically.

https://github.com/Alexpux/MINGW-packages certainly provides the better maintained repo, but it would require additional maintenance work.

OCaml itself is only tested against the gcc cross compiler (cygwin to native windows) that is shipped by cygwin and its presence is therefore assumed by other tools and build instructions as well (e.g. flexlink).
Using the repo above with cygwin’s cross compiler would be susceptible to faults (especially c++ librares are prone to ABI breakages, depending on the gcc version and gcc configuration options). And switching the c compiler and build environment (e.g. msys2 instead of cygwin) would require more patching and testing.

I’m not aware of any solution for msvc. Libraries are also incompatible depending on the msvc version and flexlink can’t deal with libraries that are compiled in the wrong way.