[ANN] codept 0.10.0

Community
1

It is my pleasure to announce a new beta release (0.10.0) of codept on opam. Codept is an alternative dependency analyzer for OCaml projects. Compared to ocamldep file-by-file analysis, codept uses whole project analysis to reduce the amount of fictitious inferred dependencies and handle module aliases uniformly.

More generally, codept’s objective is to either compute exact dependencies or emit detailed warning messages whenever exact computation would be too involved.

Beyond various bug fixes, there are three new major features in this release compared to the 0.9.0 release.

  • First, a new -deps option outputs the computed dependencies in json format. The corresponding json schema is available here or with codept -json-schema deps. Alternatively, a s-expression format (with the same structure) is available with -sexp.

  • Second, codept supports now deeply nested hierarchy of toplevel modules (see for instance this example) with the -nested option (or by manually ascribing module paths to implementation and interface files).

  • Third, codept supports now all versions of OCaml ≥4.03 (4.06+trunk included) .

7 Likes
2

What is the implication of this project?

Now that jbuilder is becoming the standard build tool, are there any plans to use it instead of ocamldep in jbuilder, and would it improve performance?

3

are there any plans to use it instead of ocamldep in jbuilder,

I do have some plans to contribute some integration of codept to jbuilder and ocamlbuild.

and would it improve performance?

No, in fact performance would slightly decrease, but dependencies computation are quite fast (~50m for computing the dependencies for the whole compiler tree).

However, codept makes sure that there is no longer case corner cases that can silently yield wrong dependencies.

For instance, ocamldep currently infers a spurious cycle A⇒A if one have two ml files

(* a.ml *)
open B
open A

(* b.ml *)
module A = struct end

Most of the time ocamldep would add dependencies, but It can also miss dependencies. In the following example, ocamldep miss the dependencies to the module C in a.ml

(* a.ml *)
module A = struct module C = struct end end
open B
open A
open C

(* b.ml *)
module A = struct end

(* c.ml *)

In both case, codept would infer the right dependencies. Nevertheless, there is is one situation where codept may fail to infer the right dependencies when one locally open a module after that a first-class module whose module type have been inferred have been opened in scope. FOr both instance, both codept and ocamldep think that the following code depends on a external module A:

module type s = sig module A:sig end end
let f (x:(module s)) = ()
let test x =
  f x;
  let module X = (val x) in
  let open X in
  let open A in
  ()

Do these situations happen often? Certainly not, but they do happen; and I didn’t like the idea of a basic (and nearly invisible) OCaml tool silently failing.

2 Likes