Version 2 of OBazl, a Bazel ruleset for building OCaml code, will soon be available. I’m letting you know early because I’ll be giving a presentation about the OBazl Toolsuite for the Bazel Exchange conference next Wed, 22 June, at 3:00 pm UDT (10:00 am CDT). It’s a virtual conference so you can tune in from anywhere. The talk will focus on some of the quirks of the OCaml build discipline and how I addressed them for the OBazl ruleset.
The tools are usable now, they’re just not yet properly documented and packaged, and in a few places there’s a little more work to be done on the code. Nonetheless there is quite a bit of documentation (CAVEAT: some of it is outdated), with more on the way soon, and there are lots of demos available. So if you’re interested in using Bazel to build your OCaml code I welcome you to take a look:
I can see how a general-purpose build system with wide language support is attractive. Though, we’re not shopping for a build system, since we’ve just migrated from OMake to dune, but it’s an interesting topic.
Does OBazl handle the -opaque flag, which allows not to rebuild dependencies when mli files did not change? For example, for our particular OMake build it was a challenge, and dune handles it transparently.
Yes, OBazl gives you pretty much complete control over that kind of stuff. I don’t have a test case where -opaque makes a difference, though; can you describe how you need to use it, or provide sample code? Is there a case where you want the build tool to infer that it is needed based on some criteria?
Regarding migration: in most cases it won’t be an either/or choice. OBazl and Dune can coexist, and before long I’ll have tooling to automatically convert dunefiles to bazel files. So I can imagine a situation where you write dunefiles for your OCaml code but use Bazel for all foreign code, and use OBazl to integrate. In other words, use Dune as a high-level language that you “transpile” to Starlark.