Before I answer this in full, I should emphasize here up front how very grateful I am that you’ve taken up this challenging task, and it would seem you’ve made a lot of progress already. You’ll see why this feels so important to me after I’ve explained my thinking further.
p1. I’m the author of Conjury, an alternative library for the OMake build tool.
That project started as a system of Perl libraries that I carted around in all my personal projects for generating cross-platform
Makefile instances (because I absolutely could not stand GNU Autoconf, and I wasn’t allowed to use it in some contexts because GPL was forbidden without paying lawyers to get permission for it).
Some time later (but still well over a decade ago) I threw away all that maddening Perl and redesigned the whole system around OMake, which I much preferred. (This was well before JBuilder, which has begotten Dune. This was also well before Google decided to release Blaze into the world as Bazel.)
Since then, I have used Conjury in a whole raft of personal unreleased projects, while OMake has perhaps not been as well-loved by the community as I was hoping it would be when I adopted it. Recently, I’ve been finding it almost as maddening as that pile of Perl I threw away, and the friction is prompting me to search for an alternative.
I’m still not a big fan of Dune, because most of my personal projects are multi-language, with a lot of C++ and C and others in the mix, and the GNU Autoconf tool suite remains a non-starter for me for all the old reasons that remain unchanged. Bazel has a lot to offer me, it does basically everything that originally attracted me to OMake, and I’m trying to get my head around how I can rewrite all the build logic in all my personal projects to use it instead of Conjury.
p2. I’m in a position to influence choices of alternative programming language at my day job.
It’s a reasonably large organization with hundreds of engineers in the software department, and over a dozen people whose full-time job is just wrangling Bazel to build and integrate an insanely large and complex monorepo full of several major systems languages, along with a whole raft of special purpose programming language including some bespoke DSLs.
With the impending release of OCaml 5.0, it’s just starting to be possible to speak seriously about it as a candidate for inclusion in our software ecosystem. It has some attractive qualities for our business case. Until recently the lack of a high quality Bazel rule set for OCaml has made the challenge of demonstrating the applicability of OCaml internally to my colleagues a pretty daunting challenge. (One reason Rust hasn’t taken off at my day job is that the integration with Bazel is considered unacceptable by our dev infra team.)
Summary: The OBazl Toolsuite looks like it has a pretty good chance of sticking the landing on point two: helping me bring OCaml into my day job. It’s not there yet (documentation of the rule set is, understandbly, lagging a bit behind the implementation), but I feel like it will probably get there in reasonable time. On the other hand, my search for a replacement for OMake remains an open problem for me. Only some of my personal projects are packaged with OPAM, and only a fraction of those are released publicly. (I have a private OPAM repository as well as a publicly visible one where I publish development branches for my packages on
opam.ocaml.org.) I need to find a tool that can deal well with multiple programming languages, not just OCaml (so that leaves out Dune), and also produce artifacts that can be delivered as OPAM packages (even if they’re written in other languages, not OCaml). I was hoping that I might turn to Bazel for that, but it looks like a daunting challenge.