kinda surprising that it still makes sense to develop your own new build system, and then do the migration to it, instead of adopting an off-the-shelf one like buck2 (or bazel/etc...). Not saying that these fancy build tools are easy to adopt, but compared to building your own? is there something remarkable that makes dune much different?
Without getting into any specifics of it - I'm sure there's people with much more experience with these tools who can comment - I'll point out that neither buck nor bzl existed when JS decided to start building their own tool in 2012. Bazel's first release was in 2015, Buck's was in 2013.
JS does have a bit of a NIH culture, but I'm not sure if that was really at play here. There just...weren't very many good build tools available at the time, particularly for a company using an unorthodox tech stack.
> I'll point out that neither buck nor bzl existed when JS decided to start building their own tool in 2012. Bazel's first release was in 2015, Buck's was in 2013.
But Dune started (according to this blog post) in 2016 and JS started seriously improving and adopting it last year. So to me Jenga sounds like a reasonable step in 2012, but pouring significant effort into migrating from Jenga to Dune (and improving Dune) in 2024 sounds more weird
Yes and no. This is all spelled out in the post, but it's a little thorny.
Dune is a rename of Jbuilder (2016). Jbuilder uses Jenga (2012) configuration files.
> By 2016 we had had enough of this, and decided to make a simple cross-platform tool, called Jbuilder, that would allow external users to build our code without having to adopt Jenga in full, and would release us from the obligation of rewriting our builds in OCamlbuild [...] Jbuilder understood the jbuild files that Jenga used for build configuration.
So in 2012 it made sense for them to build Jenga, because there weren't any good alternatives - Bzl etc. didn't exist, so they couldn't have solved their problems.
And in 2016 they had open-source code they wanted others to be able build; those people didn't want to use Jenga, and JS didn't want to rewrite their builds so that they could use something else. Thus, Jbuilder was a shim so that JS could still use their Jenga builds and others could build JS' code without using Jenga. Bzl etc., even though they existed, wouldn't have solved these problems either.
I don't know ocaml particularly well but my understanding is that only with buck2 (of those mentioned) do you have a build system with the semantics to actually compile ocaml properly.
In particular I was under the impression one needed to be able to run ocamldep before hand (or compile twice) - buck2 can do this, bazel needs hacks iirc.
I loath autotools with a passion, and it's awkward to set it all up, but it handles OCaml code just fine. We use it for multi-language projects (including OCaml) like nbdkit & libguestfs.
My team has a large ocaml codebase and a dual build system (buck2 and dune). The two have roughly similar: dune faster at the raw speed of invoking ocaml build tools, buck2 winning out when a lot of stuff has to be rebuilt and it uses distributed build system.
The major pain point is LSP integration, which has to be closely tied to the build system, since it's only by building that the LSP server can know a file's dependencies. Everything is all neatly available with dune. We've cobbled something together a bit with buck2 but it's not as nice.
