Re: [Caml-list] A way to avoid "WARNING: myocamlbuild.cmi occurs in several directories"?

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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

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
>
>

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