From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 4C92E7EE99 for ; Thu, 12 Dec 2013 23:34:04 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.46 as permitted sender) identity=mailfrom; client-ip=209.85.214.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f46.google.com) identity=helo; client-ip=209.85.214.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtICANY4qlLRVdYulGdsb2JhbABZg0JVuFiBFggWDgEBAQEHCwsJEiqCJgEFQAEbEgsBAwwGBQs7IQEBEQEFARwGE4dvAQMRpnWMWoMJhFsKGScNZIYmEQEFDIx0ghQHhDUEliqBa4EwiyqDTRgpgxeBPzs X-IPAS-Result: AtICANY4qlLRVdYulGdsb2JhbABZg0JVuFiBFggWDgEBAQEHCwsJEiqCJgEFQAEbEgsBAwwGBQs7IQEBEQEFARwGE4dvAQMRpnWMWoMJhFsKGScNZIYmEQEFDIx0ghQHhDUEliqBa4EwiyqDTRgpgxeBPzs X-IronPort-AV: E=Sophos;i="4.95,474,1384297200"; d="scan'208";a="40786242" Received: from mail-bk0-f46.google.com ([209.85.214.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Dec 2013 23:34:03 +0100 Received: by mail-bk0-f46.google.com with SMTP id u15so1119382bkz.19 for ; Thu, 12 Dec 2013 14:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GuqjXJFdhZAVz4LjXBZXziKyexIu8sMmfxQTuebPKhw=; b=jt4lZnz8EdoUHdwCn1LgoOTy6UOAo8vimiZdAO5TNpZtnN9mOOB7XxmnC4nKSDpj2d OzLO/sqkWyNIPfFmRtsft2hrQff2IE+mnHZ0Lm4peSJ5rtJRqkGP0BO+NP8MwG/miouQ rdk5c3dAtnouN3499nGCrJDty7sFkqx3C9sAtiIgDyn919D6kZQR/IgBPBMEBrLT1KeB hfNDVmkZZ/gPVq+RH8X2DOlBFEirRvcvhN1Xtx3WAiXeRgyFRWU2jogsfSV9M254X6k9 cEmG8N+L8PsiaSlKKJyfqb/h2YuBX6TgugKB74b+XPXdfzA4OSZvDbUfYL7l/Z9+YeTD EyOQ== X-Received: by 10.205.43.200 with SMTP id ud8mr3322265bkb.39.1386887642760; Thu, 12 Dec 2013 14:34:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.122.72 with HTTP; Thu, 12 Dec 2013 14:33:22 -0800 (PST) In-Reply-To: References: From: Gabriel Scherer Date: Thu, 12 Dec 2013 23:33:22 +0100 Message-ID: To: Anthony Tavener Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=bcaec52bef6d4a6bf904ed5df1da Subject: Re: [Caml-list] A way to avoid "WARNING: myocamlbuild.cmi occurs in several directories"? --bcaec52bef6d4a6bf904ed5df1da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not trying to dismiss your workflow, it's new=B9 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? =B9: 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 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 suggestio= n? > > 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 librari= es > 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, se= em > 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 > > --bcaec52bef6d4a6bf904ed5df1da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not trying to dismiss your workflow, it's new= =B9 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, i= nstallation always took a time neglectible when compared to compilation or = (even more so) unit-testing. When you say "immediate use", is the= re any reason other than speed for avoiding a local install? Did you measur= e the speed difference?

=B9: we've been aware of "huge monolithic buil= ds" used in some OCaml-using companies, but they generally use a singl= e build system to direct all the build, instead of several separate-but-con= nected islands of libraries. I also use Stog, a static blog engine by Maxen= ce Guesdon, that allows plugin and has built-in support for finding them th= rough ocamlfind. In my periods of Stog hacking I've always frequently m= odified and rebuild the plugins, in synchronization with evolution Stog'= ;s code itself; but then I re-install each of them separately and never fel= t that to be a problem.


O= n 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 switc= hed 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.

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

Now that I'= m using ocamlfind (with ocamlbuild) these _build directories are included i= n a more general sense... causing multiple myocamlbuild.cmi's to be see= n -- resulting in "findlib: [WARNING] Interface myocamlbuild.cmi occur= s 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 anoth= er suggestion?

The obvious thing is adding an inst= all step which dumps the interesting library files in a local lib dir. But = then I'd have two kinds of install: a "package" install (usin= g 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)
=A0App1 : Lib2 Lib3
=A0App2 : Lib1 Lib2
=A0Lib1 : -
=A0Lib2 : -
<= div>=A0Lib3 : Lib1

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

No "install", as these are all in flux. The l= ibraries 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 expl= icitly built and separately installed units? (Note: I do have some slowly-e= volving 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 librar= y dependency like this yet. The tools, or at least the examples of how to u= se 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 t= oo!

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!

=A0-Tony


--bcaec52bef6d4a6bf904ed5df1da--