caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Anthony Tavener <anthony.tavener@gmail.com>
To: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: [Caml-list] A way to avoid "WARNING: myocamlbuild.cmi occurs in several directories"?
Date: Thu, 12 Dec 2013 14:47:29 -0700	[thread overview]
Message-ID: <CAN=ouMTZQ_gEjZNg+z4GB_KsbNg8PV=rVfX2YnzGhcGK-Oimfg@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

(Or a better structure to my build process?)

I've recently switched to OPAM and ocamlfind (from manual management and
makefiles).

I have some libraries which undergo frequent changes -- as frequent as
application code. For these, I don't "install" after every change; instead
I refer to the _build directory.

  ocaml_lib ~extern:true ~dir:"/home/anthony/src/gui/_build" "gui";

Now that I'm using ocamlfind (with ocamlbuild) these _build directories are
included in a more general sense... causing multiple myocamlbuild.cmi's to
be seen -- resulting in "findlib: [WARNING] Interface myocamlbuild.cmi
occurs in several directories"

Does someone know a way to avoid the inclusion of these spurious
myocamlbuild.cmi's, or to suppress the warning, or have another suggestion?

The obvious thing is adding an install step which dumps the interesting
library files in a local lib dir. But then I'd have two kinds of install: a
"package" install (using ocamlfind, and OPAM-friendly), and this
immediate-use local install. Yuck, I say.


Ultimately what I strive for is install-less build, and build dependency on
local library changes. For example:

(unit : dependencies)
 App1 : Lib2 Lib3
 App2 : Lib1 Lib2
 Lib1 : -
 Lib2 : -
 Lib3 : Lib1

<~/Lib1> touch lib1file.ml
<~/App1> make
  Build Lib2
  Build Lib1
  Build Lib3
  Build App1

No "install", as these are all in flux. The libraries are just like the
app-code but shared. Like they used to be before the world of package
management. ;) I'm sure others must still do this for internal development
too? Or does everyone work with libraries as explicitly built and
separately installed units? (Note: I do have some slowly-evolving libraries
which I install as packages via OPAM.)

To rephrase: Am I doing it all wrong? :D

I haven't figured out how to get ocamlbuild to handle library dependency
like this yet. The tools, or at least the examples of how to use them, seem
very geared toward usage of infrequently-changed packages. So any tips on
an example of using ocamlbuild in this manner would be great too!

I'm always hesitant to pester the mailing list, but it generally follows
days of frustration on my part, and I don't know any other OCaml people, so
thank-you!

 -Tony

[-- Attachment #2: Type: text/html, Size: 2931 bytes --]

             reply	other threads:[~2013-12-12 21:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 21:47 Anthony Tavener [this message]
2013-12-12 22:33 ` Gabriel Scherer
2013-12-12 23:57   ` Anthony Tavener
2013-12-13  0:12     ` Daniel Bünzli
2013-12-13  3:34       ` Stephen Magill

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='CAN=ouMTZQ_gEjZNg+z4GB_KsbNg8PV=rVfX2YnzGhcGK-Oimfg@mail.gmail.com' \
    --to=anthony.tavener@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).