No, and it’s really quite opinionated on that point. Rules are written in Starlark period full stop, and Starlark isn’t Python because Python is too powerful for people entrusted to write
*.bzl files to be allowed to use it. And nobody complains to the Bazel gods about that, unless they want to be smitten down.
Bazel does allow you to call out to an external build system for constructing an imported package, and this is what jin/rules_ocaml does for building an external OPAM package, but it isn’t very robust at building an OCaml program from a list of
.mli files— that will fail in mysterious ways if you blow on it gently, i.e. try to build anything moderately complicated. See below.
A reason OCaml is difficult for Bazel is that OCaml is finicky about build order in ways that all the various languages Bazel likes— because G***** likes them and them alone— are not. The
ocamldep tool produces information that Bazel quite deliberately refuses to give you an automatic way to use in feeding the dependency graph. It is a matter of principled design that Bazel insists you manually and explicitly specify all the dependencies in a rule and they are not automatically discovered. It looks at our
ocamldep tool and raises its holy symbol and shouts in a broken dead language until it goes away.
As you might imagine, that makes compiling the
.cmx files for a library that has a complicated internal dependency graph currently discovered quietly and automatically by
ocamldep a bit of a problem. Which basically means, that if you want a decent OCaml toolchain for use with Bazel, you have to wrap it somehow so that when you write something like this…
name = "my_library",
srcs = glob(["*.ml", "*.mli"]),
…the code for that rule compiles all the
.o files, and everything else, in the right order— because Bazel isn’t going to help you by slurping the output of
ocamldep into its dependency graph like other tools will do.
An additional complication is that when you provide a list of source files in a
srcs= parameter to a rule, the convention is that the list is unordered, and conventionally many shops uses a Starlark formatter that automatically alphabetizes such lists and a commit guard on the repository that requires the
BUILD files to be fed through the auto-formatter. Which means you can’t require the
srcs= list to be specified in the correct build order for OCaml.
To do this right, you need to be very clever in the Starlark code that compiles a library or a program, more clever than anybody has yet tried to be. I don’t think I would try unless I was getting paid.