SkillsCast coming soon.
The build discipline of the standard OCaml toolchain is complex and opaque. In this talk I will address some of the challenges I encountered developing the OBazl ruleset. I'll outline four major quirks in the build discipline and the methods developed to address them. Along the way I'll touch on most of the major features of the OBazl toolsuite.
I'll start with the concept of a module
, which is central to both the language and the build discipline. A module is just a pairing of a structure (implementation) and a signature (interface). Conceptually, modules are relativey simple, but compiling modules is a surprisingly complicated affair.
Another major challenge for any OCaml build system is namespacing. The OCaml language is namespaced (in a sense I'll explain), but unlike many other languages with namespacing, OCaml does not define a mapping from namespaces to the file system. The compiler understands module "paths" like A.B.C
, but it does not interpret such a segmented name as a file system path like A/B/C
; rather, it will search for each segment as a file independent of directory. In other words, the module namespace is flat, which can lead to name collisions. To address this OCaml supports a mechanism called "module aliasing" that can be used
to emulate filesystem-based namespacing. OBazl rules support two forms of namespacing, top-down (namespaces select their submodules) and bottom-up (modules elect namespace membership).
A third major challenge is handling compiler extensions. OCaml does not have a macro system, but it does support a small number of compiler extension points; these are usually referred to as "Pre-Processing eXtension", or PPXes. They require special support in a build system.
Fourth, most OCaml projects use the OPAM package manager. The OBazl toolsuite includes set of tools that support seamless integration of OPAM into the OBazl ecosystem.
Finally, I'll touch on some of the tooling I've developed to make it easier to use OBazl. Since OBazl, being a Bazel ruleset, requires that all dependencies of each build target be explicitly enumerated, generating and maintaining the BUILD.bazel files for any substantial project could involve a lot of tedious, error-prone work. Fortunately most of this can be automated, and I will give a brief overview of some tools addressing this issue.
YOU MAY ALSO LIKE: