Topological sort on _build/default/lib/*/byte/*.cmo?

Learning
1

  1. I have a project that builds via dune build -w

  2. I am loading it into utop via manually generating #load "..." for files in find _build/default/lib | grep cmo$

  3. Apparently the order or loading the cmo matter. For example, suppose lib/A.ml uses a function for mlib/B.ml then:

// good
#load ".../b.cmo"
#load ".../a.cmo"

whereas

// bad
#load "../a.cmo" // unresolved ref to function in B
#load "../b.cmo"

Question: is there a way to do a topological sort on thees *.cmo files, or a way to tell OCaml to “load all dependencies” ?

2

There is a way but it’s not supported by OCaml’s upstream tooling. I think dune utop does that for you.

3

There is a way to basically do this when using a recent dune version (>= 3.6):

#use_output "dune ocaml top-module foo.ml";;

(see: Toplevel Integration — Dune documentation)

This will load foo.ml and all its dependencies in the toplevel (without using the foo.mli interface if there is one, so you can access Foo’s internal functions).

4

@dbuenzli @Armael :

the problem with both of these, if they seem to fight with dune build -w over some directory (I have no idea why)

dune utop; echo "==="; dune ocaml top-module foo.ml
Error: A running dune (pid: 1359440) instance has locked the build directory.
If this is not the case, please delete _build/.lock
===
Error: A running dune (pid: 1359440) instance has locked the build directory.
If this is not the case, please delete _build/.lock


ocaml --version; echo "==="; dune --version;
The OCaml toplevel, version 5.0.0
===
3.6.1

Do I need to upgrade either ocaml or dune ?

5

Indeed I haven’t tried to simultaneously run dune build -w and the dune ocaml top-module invocation. Maybe the conflict is worth reporting on the dune side? (or maybe that’s not a supported use case, I have no idea)