I thought this might be good to share with others. I had Windows builds of my build system (“dk”) failing because they were taking 2 hours to run (2hr time limit on public GitLab CI). The build is just regular opam with dune. With separate jobs to prepare a cache, I could bring it just under 2 hours. But I really didn’t like how brittle and hacky that solution was. So I decided to use the distributed caching feature of dk to bootstrap the building of dk. And now that I’ve scripted enough opam / dune / ocamlbuild / relocatable OCaml functionality into dk build rules (package: CommonsLang_OCaml), I think it could be useful to some opam package maintainers.
I picked ocamlearlybird as my representative package for no reasons other than I had used it before and it seemed representative of the size of “normal” OCaml projects. It is on GitHub so setup-ocaml is available.
- 13 m 56 s to build
ocamlearlybird.exeon GitHub windows-latest (2 vCPUs with 8 GB of RAM) the first time, but faster at 10 m 50 s after setup-ocaml initializes the cache. For CI, 10 m 50 s is the relevant number; for desktops, 13 m 56 s is. - 8 m 48 s to build from scratch after running my adoption build rules (module:
CommonsLang_OCaml.Dk.OpamLock.Adopt@1.1.14). That performance isn’t very impressive for a binary cache, but that was only caching a few special packages like Dune and the relocatable OCaml compiler. This is the quick-setup branch in the website below - 2 m 18 s to build from scratch after we’ve also created GitHub release jobs to store intermediate build artifacts. dk can “restore” from one or more GitHub releases and use them as caches: each release has zip files, and dk knows how to use HTTP Range requests to somewhat efficiently get intermediate build artifacts (ex. binary opam packages, the relocatable OCaml compiler). This is the high-performance branch in the website below
Net: If OCaml package maintainers adopted and created these dk-based GitHub releases, then regular OCaml users could access a loose federation of binary caches on their desktops or in CI.
Net Net: I’d love to see if dk can take a stab at lowering the cost curve for AI. Today’s AI is very much like opam today: source in + artifacts out, with no sharing of artifacts. But share artifacts and the cost/waste/time/complexity goes down.
AI Provenance: The dk packages (ex. CommonsLang_OCaml) have been 100% AI generated and maintained since June 2026, and “dk” itself was hand built but AI assisted since June 2026.
Caveats: I haven’t really tested out macOS and Linux in a long time, but they are in CI. Actually, for my own safety, most of my testing on Windows is in Windows CI to avoid AI badness. And I didn’t realize until too late that ocamlearlybird wasn’t available for OCaml 5.5 (the first conventional relocatable version), so I have mostly tested with relocatable-patched OCaml 4.14. And I haven’t yet separated MSVC packages from MinGW on Windows; you may need Visual Studio on Windows. Expect bugs!
Thanks: @dra27 for spending years getting relocatable OCaml working!
Apology in advance: I think this has some overlap with dune pkg. But I’m on Windows and haven’t tried it out.
Links:
- https://jonahbeckford.github.io/ocamlearlybird/ (mini website with performance measurements, how to adopt)
- https://diskuv.com/dk/ (the fine details of the build system; not required for this discuss post)