Thinking about this some more, I’d like to offer what I hope the compiler team will view as constructive criticism— an observation of a way the compiler tools work today that I believe can be improved— that might help simplify what the larger community sees as an undesirable complexity.
The current tools use a model for constructing libraries that looks very familiar to C/C++ programmers at first glance, but owing to the peculiarities of modern OCaml, is actually a bit more complicated. Here’s what I mean by that:
The files comprising a typical C/C++ library include…
- a static archive (
libname.a)
- a dynamic library (
libname.so or libname.dylib)
- a set of header files (
name.h, folder/name1.h, folder/name2.h et cetera)
The files comprising a typeical OCaml library include…
- a bytecode library file (
name.cma)
- the compiled interfaces (the
.cmi files)
- the bytecode compiled modules (the
.cmo files)
- optionally, the binary annotation files (the
.cmt and .cmti files)
- optionally, where the library has
external values:
- the auxiliary static library (
libname.a)
- optionally, the dynamic “stub” library (
dllname.so)
- optionally, where the native compiler is available:
- the native library files (
name.cmxa and name.a)
- the native compiled modules (the
.cmx files)
- optionally, the native plugin (
name.cmxs)
- optionally, the source code (the
.ml and .mli files)
Various competing ways of managing the complexity of the C/C++ library distribution problem exist, and most of them use peripheral tools apart from the C/C++ compiler toolchain to deal with it. For example pkg-config from freedesktop.org. The venerable ocamlfind tool takes a similar approach.
I used to work at Apple, and one thing I’ll say the Apple compiler toolchain has long had going for it is the way frameworks are built in, and I think it would be an improvement to the OCaml ecosystem if the core OCaml toolchain had a similar conceptual framework for modeling the distribution bundle of OCaml libraries. Leaving this out of the compiler chain for tools like ocamlfind and dune and opam to manage has, I would say, resulted in more complexity than if the compiler tools themselves provided a unified systematic way of bundling libraries, and I think something like the way Apple frameworks work would be a great help.
In other words, instead of ocamlfind ocamlc -requires unix... it would be better I think if it were just ocamlc -F unix... instead. In that world, the OCaml tools would systematically define the format of an OCaml “framework” (which includes all the required and optional artifacts I outlined above), the build tools like dune and bazel and make could use the toolchain to produce them rather than write their own logic to conform to the way ocamlfind has done it historically, and the packaging tools like opam and apt and pkgsrc treat packages that contain one or more frameworks as versioned units of dependency management.
Note well: the whole world of PPX artifacts is an additional complexity in OCaml library distribution that I think isn’t going to get any easier for packaging and build tools to handle without something like this “framework” concept I’m talking about.
I hope the compiler team finds this suggestion constructive and useful. I’d be willing to collaborate with the compiler team and others in the community in a task group to design such a framework format.
