I’m in the middle of building an OCaml-based installer generator; an introduction is at dkml-install-api and the API is at dkml-install-api/odoc. The first target will be to generate a standalone installer for OCaml on Windows. However, the installer generator will be usable by any OCaml maintainer for their own Windows/macOS/Linux software. With that in mind, I’ll respond to a few things you mentioned:
-
Easy way to build and distribute OCaml executable …. If you mean just distributing a single executable, I’m sure you’ve already come across the Generating static and portable executables with OCaml post by Louis Gesbert at OCamlPro. It might not be easy, but at least it is formulaic. But you may need to do more than just distribute a single binary. For the Windows installer we need Visual Studio, Git and a Unix shell installed, an OCaml system compiled in-place on the end-user machine, a system PATH tweak, some binaries and at least one working Opam switch with preconfigured Opam repositories.
-
build (preferably) statically-linked executables. Much has been written elsewhere about static linking vs dynamic linking. I lean towards dynamic linking because security auditing is much easier for the end-user, and dynamic linking is often required to comply with fellow maintainers’ software licenses that don’t have static linking exceptions. So … and I think this will interest you @mjambon … I’ve been using the Python’s PEP-driven “manylinux” standard in-house. Basically, it is a spec for a conforming Python distribution to have a set of shared libraries (ex. libc, libglib2) with known minimum versions on Linux, and test environments (Docker containers) to make sure any Python binary extensions you develop can be distributed on all the major Linux distributions. The manylinux Docker containers can catch Linux distribution gaps in C libraries used in some OCaml packages (ex. capnproto#1414) and is fairly easy to add to CI (ex. capnproto#1415). When Linux becomes generally available in
dkml-install-api, I’m expecting to re-use these manylinux Docker containers to build portable dynamically-linked Linux binaries. -
publish binary packages for the popular package managers … build such binaries and make them available via
pip. Both system package managers and language package managers are being discussed. I’ll clarify my language: the installer generator I’m building is design to install standalone software on the end-user system (sometimes that will involve system package managers like Homebrew, yum, apt) but uses a language package (opam) to build the installer itself. In fact Opam is quite capable of downloading binaries, anddkml-install-apimakes heavy use of that feature. See the .opam file in dkml-component-curl for an example where a binary executablegeneric/bin/curl.exeis installed that is either a) a download of curl.exe on an end-user Windows machine or b) symlink to the system curl executable on an end-user macOS/Linux machine. // I think it is a straightforward extension to do the local dev machine experience similar topip install xyz, but someone else would need to focus on that.
Although dkml-install-api is not yet released, if you or anyone else is interested in contributing or nudging the development, file an issue / send a PR / message me on Discuss.
Good luck, Jonah