Trickier than it seems, because there are several different kinds of depgraph.

Depgraphs are fully transitive wrt build actions: when you build a target, its complete depgraph gets built.

OTOH, the kind of transitivity involved in constructing build commands is only partially transitive. Interface depgraphs are treated differently than imlementation depgraphs.

Each ocaml_module target propagates its module depgraph to its clients. That includes its own interface dep, but excludes the interface deps of its module deps.

For example, suppose A.cmo depends on B.cmo, and A.cmi depends on B.cmi. A.cmo’s depgraph will include A.cmi and B.cmo as direct dependencies. And since B.cmo depends directy on B.cmi, the latter will be included indirectly in A.cmo’s depgraph. But A.cmi’s depgraph will not be included; only A.cmi will be included in A.cmo’s depgraph.

Now suppose A.cmi depends on C.cmi in addition to B.cmi, but neither A.cmo nor B.cmo depend C.cmo. [Can this happen?] Then A.cmo depends on A.cmi, but not C.cmi; iow, it only uses the API declared by A.cmi. Building A.cmi will ccause C.cmi to be built, but the result need not be added to the depgraph of A.cmo, because the compiler will not need to find C.cmo in order to compile A.cmo. It only needs to find A.cmi.

To build A, we need B.cmi and B.cmo on the search path. Since A.cmo depends on B.cmo, and B.cmo depends on B.cmi, …​ B.cmi must be listed as an input the the A build action, so it must be provided by the B.cmo depgraph. But it is not provided by the A.cmi dep, even though A.cmi depends on B.cmi.

Build tasks involve explicit build commands, but they also always involve a critical bit of information that is often hidden or only implicit, namely the graph of the target’s dependencies. Dependency management is a well-known pain point for OCaml builds; the entire dependency graph of a build target must be made available to the compiler, and for archive and executable targets, must be listed explicitly on the command line in dependency order. By and large, managing dependencies by hand is infeasible for all but the most simple projects.

The strategy for managing dependencies adopted by Bazel (and thus OBazl) is starkly different from that of most other build systems.

[FIXME: three points:

Many build systems, Dune included, conflate dependency discovery and the build process. For example, Makefiles for building OCaml projects usually run ocamldep to generate .depends files listing dependencies, and build targets depend on these dynamically generated files. Dune build stanzas list direct dependencies, but indirect dependencies are discovered (using ocamldep) and added to the build dependency graph as part of the build process.

By contrast, Bazel enforces a strict separation between dependency discovery and the build process. All dependencies must be explicitly enumerated for Bazel before the build process begins; discovering and adding a dependency in the course of the build process is disallowed. This is a necessary feature of any hermetic (replicable) build process: if you want to design a replicable experiment, you start by fixing the initial conditions. Build systems that allow dynamic discovery and injection of dependencies cannot guarantee hermeticity. [WARNING: this is not accurate, to be revised]

The downside of having to explicitly enumerate the entire dependency graph for a project is that you have to explicitly enumerate the entire dependency graph for the project. But this is obviously a task that can and should be addressed by a build tool, just as it is for systems that do this discovery during the build process. The only difference is that for Bazel we run the dependency discovery tool before the build process commences, and we record its results and pass them as input to the build process.

Version 2 of OBazl includes tooling that can largely if not entirely automate the enumeration of dependencies. Currently there are some cases where it is difficult to discover all dependencies; for example targets that involve lots of indirection, -open arguments and include directives in source files. A goal of the OBazl project is to perfect this tool so that can always emit complete and correct dependency graphs.

Another notable feature of OBazl with respect to dependencies is that we get correct ordering for free, so to speak. Dependency ordering for compiler inputs, and for most build tools, is expressed syntactically, as list ordering (which is in part why managing deps in such systems is difficult). But OBazl maintains dependencies as a graph structure, so ordering is expressed as hierarchy. The only way to express a dependency of A on B is to list B explicitly in the deps attribute of A; there is no way to express it as the list B A, as one must do on the compiler command line. In particular, listing ["A", "B"] in a `deps` attribute does not express a dependency of B on A. In fact, it could be the case that A depends on B (either directly or indirectly), so when we serialize the graph derived from this list we will get B A. It follows that dependencies can be listed in any order; you can list them in alphabetical order if you wish.

The critical feature here is that Bazel provides out-of-the-box support for merging dependency graphs. If your dependencies are expressed as ordered lists, and you have multiple dependencies, then you have the task of merging the ordered lists in such a way that dependency order is maintained, which is non-trivial, since the same item may occur in different contexts in more than one list. [TODO: simple example]. Bazel provides a depset facility that handles such merging automatically and efficiently. OBazl rules use depsets to manage all dependencies.

deps that require special handling by the build engine: runtime data deps; runtime code deps (plugins); ppx-codeps

solves same problem as Dune’s (select …​ from …​) ( "alternative dependencies")