caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Christian Lindig <lindig@gmail.com>
To: caml-list@inria.fr
Cc: antonbachin@yahoo.com, Gabriel Scherer <gabriel.scherer@gmail.com>
Subject: [Caml-list] Coverage profiling with bisect_ppx, Oasis, and OCamlbuild - best practice?
Date: Thu, 19 May 2016 19:46:17 +0100	[thread overview]
Message-ID: <43B63E1B-768C-4C2F-ADCB-C2C994A99EB6@gmail.com> (raw)


Bisect_ppx (https://github.com/aantron/bisect_ppx) is a great tool for instrument code for coverage profiling. I’d like to explore the best way to use this in a bigger project that is built with Oasis/OCamlbuild. In particular, I’d like to find a high-level way to specify that I want variants of binaries produced, analogous to 

	binary.native
	binary.byte
	binary.coverage (say, for native binary with coverage instrumentation)

without duplicating too much code in the _oasis file. It is my goal to produce such binaries for installation and hence would like to avoid doing this sequentially like in 

	make opt; make clean; make byte; make clean 

but rather have one target that produces all variants. If this is impossible, I’d revert to building variants sequentially. The reason I expect this to be difficult is that an object file produced with and without instrumentation looks the same and thus it might be difficult for the build system to understand that these need the be rebuilt. 

Code instrumented for coverage needs to be compiled with the corresponding PPX. OCamlfind and OCamlbuild abstracts this nicely. For compiling example.ml it’s enough to say:

	ocamlbuild —use-ocamlfind -pkg bisect_ppx example.native

It is less obvious how to organise this in a bigger project. (For now I add rules 

	<**/*.ml{,i,y}>: pkg_bisect_ppx 
	<**/*.native>: pkg_bisect_ppx 

to the _tags file generated by Oasis.) I believe the problem already arises with profiling and debugging builds and I would be happy to learn how OCamlbuild can be directed via myocamlbuild.ml to do this. 

— Christian


             reply	other threads:[~2016-05-19 18:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 18:46 Christian Lindig [this message]
2016-05-19 19:03 ` Gabriel Scherer

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=43B63E1B-768C-4C2F-ADCB-C2C994A99EB6@gmail.com \
    --to=lindig@gmail.com \
    --cc=antonbachin@yahoo.com \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).