DAG of .ml[l/y] files in a directory

Learning
, , ,
1

What workflow is used to create and print the DAG illustraing the dependencies between .ml[l] files in a directory?
In my specific case I’m trying to illustrate the DAG for the utop/src/lib with uTop_main.ml being the driver, there’s only nine nodes and
implemented this manually as an adjacency list.

let lib_dag = [(uTop_token.ml,[]); (uTop_styles.ml,[uTop_token.ml;uTop_compat.ml;uTop.ml]) (uTop_lexer.mll,[uTop_token.ml]); (uTop_history.ml,[]); (uTop_private.ml,[]); (uTop_compat.ml,[]);
(uTop_complete,[uTop_token.ml;uTop_lexer.mll;uTop_compat.ml;utop.ml]);
(utop.ml,[uTop_history.ml;uTop_private.ml;uTop_compat.ml]);(uTop_main.ml, [uTop_token.ml;uTop_styles.ml;uTop_lexer.mll;uTop_history.ml;uTop_private.ml;uTop_compat.ml;uTop_complete.ml;utop.ml])]

But is there a particular way using shell scripts or ocaml to automate this and produce a .png illustration of the graph? Would this strategy be useful for studying Stdlib and summarizing large code base directories?

2

Maybe, GitHub - sim642/odep: Dependency graphs for OCaml modules, libraries and packages ?

3

Thanks for the plug!

For reference, odep dune | xdot - allows interactive viewing, which includes the following (in addition to other dependency packages):

image
image1266×1319 157 KB

Now looking at it, I think there’s something strange happening in odep here. The dune library and the dune executable both being called utop is mixing some things up… So there’s a bit too many arrows between the two, but the arrows inside the library should be right.

3 Likes