I'm not trying to dismiss your workflow, it's new¹ to me and interesting. But is there really such a benefit to the "install-less" part of your setup? On the project I've worked on, installation always took a time neglectible when compared to compilation or (even more so) unit-testing. When you say "immediate use", is there any reason other than speed for avoiding a local install? Did you measure the speed difference?

¹: we've been aware of "huge monolithic builds" used in some OCaml-using companies, but they generally use a single build system to direct all the build, instead of several separate-but-connected islands of libraries. I also use Stog, a static blog engine by Maxence Guesdon, that allows plugin and has built-in support for finding them through ocamlfind. In my periods of Stog hacking I've always frequently modified and rebuild the plugins, in synchronization with evolution Stog's code itself; but then I re-install each of them separately and never felt that to be a problem.


On Thu, Dec 12, 2013 at 10:47 PM, Anthony Tavener <anthony.tavener@gmail.com> wrote:
(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