From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: octachron <octa@polychoron.fr>, Caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] [ANN] codept 0.9: an alternative dependency analyzer for ocaml projects
Date: Mon, 20 Feb 2017 18:29:02 +0100 [thread overview]
Message-ID: <1487611742.6296.10.camel@gerd-stolpmann.de> (raw)
In-Reply-To: <69663638-7572-6553-1ef3-edd8f7c0ea9f@polychoron.fr>
[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]
This is really great. I'm now using more and more packed libraries, and
hence nested modules are much more frequent, and I think ocamldep is no
longer good enough in this world.
I figured out that you can often switch to codept using
OCAMLFIND_COMMANDS="ocamldep=codept" make
when ocamldep is invoked via ocamlfind.
My first testing results are positive. Thanks for this huge
contribution.
Gerd
Am Montag, den 20.02.2017, 11:25 +0100 schrieb octachron:
> 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
>
>
>
--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de
My OCaml site: http://www.camlcity.org
Contact details: http://www.camlcity.org/contact.html
Company homepage: http://www.gerd-stolpmann.de
------------------------------------------------------------
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
prev parent reply other threads:[~2017-02-20 17:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 10:25 octachron
2017-02-20 17:29 ` Gerd Stolpmann [this message]
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=1487611742.6296.10.camel@gerd-stolpmann.de \
--to=info@gerd-stolpmann.de \
--cc=caml-list@inria.fr \
--cc=octa@polychoron.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