Firstly, your dissent is noted, and appreciated (thanks for engaging with the discussion!). We have had many, many build systems for OCaml in its rich history, and almost all of them still work (ocamlbuild, oasis+ocamlbuild, omake, make, cmake, all lurk within the older corners of opam-repository and are regularly bulk built).
I’m entirely supportive of documenting alternative recommended build systems for OCaml, iff:
- the recommendation is meaningfully tested across the architecture/OS combination supported by the OCaml compiler.
- it has some users who are motivated to keep it working, and step up to do the work.
- it has an interoperability story (even if manual) with publishing to the opam repository, which is the gathering space for the OCaml community.
There will never be a requirement to use Dune to participate in package set in the OCaml.org website. The only requirement is the presence of an opam file in your package to indicate how to build your contribution, and how it can depend on other packages from the community via dependencies, and how it should be used (via its license).
There were some related talks (such as Meta’s buck2 for OCaml) at the recent OCaml Workshop. I, and I’m sure many others, would be delighted to see more writeups and presentations on improved build approaches in our various gatherings.
In the meanwhile though, Dune is a clear frontrunner for the default recommendation, as objectively counted by the package set in the opam repository. This does tell me that for the dune team, it’s important to prioritise negative feedback to make sure they don’t accidentally stomp on a smaller set of users. For example, @xavierleroy (and others) have noted that the default warning flags in development mode are too expansive and diverge from the compiler defaults. I’ve created dune issue #8645 to track this; please do create others as you come across papercuts or interoperability problems with your own developments.