Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: octachron <octa@polychoron.fr>
To: Caml-list <caml-list@inria.fr>
Subject: [Caml-list] [ANN] codept 0.9: an alternative dependency analyzer for ocaml projects
Date: Mon, 20 Feb 2017 11:25:57 +0100	[thread overview]
Message-ID: <69663638-7572-6553-1ef3-edd8f7c0ea9f@polychoron.fr> (raw)

Dear all,

It is my pleasure to announce the release on opam of codept's first 
alpha version:
codept is a dependency analyzer for OCaml projects and an alternative to 
ocamldep: https://github.com/Octachron/codept .


Compared to ocamldep, codept major features are:

     − whole project analysis
     − extensive warning and error messages
     − uniform handling of delayed alias dependencies (aka "-no-alias-deps")
     − experimental full dependencies, when dependencies up to 
transitive closure are not precise enough

Both ocamldep and codept compute an over-approximation of the dependency 
graph of OCaml projects. However, codept uses whole project analysis to 
reduce the number of fictitious dependencies inferred at the project 
scale, whereas ocamldep is, by design, limited to local file-by-file 
analysis.

Consequently, bugs notwithstanding, codept computes an exact dependency 
graph in any situation that does not involve unknown external modules or 
first class modules, and is still reliable in some standard use cases of 
first class modules.

Moreover, codept will emit warning messages any time it encounters a 
source of potential inaccuracies in the dependency graph, thus ensuring 
that computed dependencies are always exact in the absence of warning 
messages.

Another important point is that codept's whole project analysis feature 
makes it possible to handle uniformly the delayed dependency aspect of 
module aliases introduced by the "-no-alias-deps" option.

At last, in situation where dependencies up to transitive closure are 
not precise enough, codept's experimental "-expand-deps" option can 
track more precisely type aliases induced dependencies, making it easier 
to track all cmi files required to compile a given file for instance.

Basic performance measures indicate that the average time increase when 
compared to ocamldep.opt ranges between 10% to 50%.

Codept can be used directly as a drop-in replacement to ocamldep. 
However, to be fully effective codept needs to be feed information on 
the whole project. Consequently, some build systems require some 
adaptations. As a first step, codept is distributed with an ocamlbuild 
plugin subpackage that adapts ocamlbuild dependency computation to 
codept's needs. Integration with other build tools is still a work in 
progress.

More information is available at https://github.com/Octachron/codept .

− octachron



             reply	other threads:[~2017-02-20 10:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 10:25 octachron [this message]
2017-02-20 17:29 ` Gerd Stolpmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69663638-7572-6553-1ef3-edd8f7c0ea9f@polychoron.fr \
    --to=octa@polychoron.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox