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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 152247EE99 for ; Fri, 13 Dec 2013 00:57:41 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=74.125.83.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of anthony.tavener@gmail.com designates 74.125.83.52 as permitted sender) identity=mailfrom; client-ip=74.125.83.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ee0-f52.google.com) identity=helo; client-ip=74.125.83.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-ee0-f52.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtICAF5MqlJKfVM0lGdsb2JhbABZg0JJDLhYgRYIFg4BAQEBBwsLCRIqgiUBAQQBQAEbEgsBAwELBgULDS4hAQERAQUBHAYTh28BAwkIpwOMWoMJhFMKGScNZIYmEQEFDIx0ghQHhDUEiUOMZ4FrgTCLKoNNGCmDF4FeHA X-IPAS-Result: AtICAF5MqlJKfVM0lGdsb2JhbABZg0JJDLhYgRYIFg4BAQEBBwsLCRIqgiUBAQQBQAEbEgsBAwELBgULDS4hAQERAQUBHAYTh28BAwkIpwOMWoMJhFMKGScNZIYmEQEFDIx0ghQHhDUEiUOMZ4FrgTCLKoNNGCmDF4FeHA X-IronPort-AV: E=Sophos;i="4.95,475,1384297200"; d="scan'208";a="48662568" Received: from mail-ee0-f52.google.com ([74.125.83.52]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Dec 2013 00:57:40 +0100 Received: by mail-ee0-f52.google.com with SMTP id d17so552976eek.11 for ; Thu, 12 Dec 2013 15:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KO+lsyVaBK520K1WhXwiseehXwGFcNbY9nSXVxLDBOA=; b=Gg8xE/ItDUoaqi7h/w3RipdnfEVk1SmcHq6l4llH6prgXiqh9zUkV0j0Xq3D26PQXF t+84Mx0eEn6L/1gJU29m2j/PKAf9IwtmyfUQqzMzu9lel0VZh5XeSK/Jm60ty+A6R/ub PZXTnIzIKS9A8MjJww18nhIfFobb4tafJCl9diAtCFZ3W8TCYB+4nH+svinHgDIVjIfw epYBZf5D+5Bqtljj9bMe5zCZ+M7bZtLll2gYMp5ylpwIcyAOMXXRzX7P7ZXRMvkyvnkR L8b49c8qbw1bZd5p2fYofgFnERDgpN7ELJzdU7YjNz5bn1Yny10a23GAEWLpG8/UQ2XZ /qZg== MIME-Version: 1.0 X-Received: by 10.14.219.4 with SMTP id l4mr10536357eep.94.1386892659790; Thu, 12 Dec 2013 15:57:39 -0800 (PST) Received: by 10.15.90.202 with HTTP; Thu, 12 Dec 2013 15:57:39 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Dec 2013 16:57:39 -0700 Message-ID: From: Anthony Tavener To: Gabriel Scherer Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=047d7b62492c541b7704ed5f1c9c Subject: Re: [Caml-list] A way to avoid "WARNING: myocamlbuild.cmi occurs in several directories"? --047d7b62492c541b7704ed5f1c9c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The benefit is editing library code as freely as application code. If I have to do a separate build/install, and then build/install up the hierarchy, this becomes a significant pain if it's a bit of code which I'm doing a edit/test cycle with. For example, say I have some procedural noise function (in noiselib) which I'm enhancing, with respect to a particular application (app), and we have this dependency: app > texturelib > noiselib. I'd rather not have this process to iterate with: make; make install_local cd ../texturelib make clean; make; make install_local cd ../app make clean; make Also note the "install_local" as opposed to "install" -- this would be a minor ugliness too. I have applications which rely on more stable versions of the libraries installed system-wide, and infrequently updated. If I'm needing a special install process anyway, why install at all? Seems better to use it in-place. Creating an "app-local" version of the function in question (extending modules via include) can work, and I do this, but sometimes the changes are more complex or pervasive than a single function -- and you don't always realize the changes are going to escape their initial scope. I regularly develop libraries in parallel with application code. This was also the case in the large studios I've worked in (games). Typically there are a few tiers of library code -- where a library is common code, rather than rigid code. In practice the library code doesn't change much because other code depends on it and has fixed the interfaces, but when you do work with library code, it's in the context of application and needs the benefit of easy edit/test iteration. I think another view of libraries is much more standalone, with unit-tests to determine correct behavior. Again, this can apply in some cases, but perhaps it's less common with an interactive artsy application like games -- where correctness is more a matter of end-result behavior, rather than something you can build good unit-tests for. Thank-you for asking, Gabriel... it helped me sort some of this out for myself too! The stumbling blocks I'm encountering have made me feel a bit uncertain -- there's an impedance mismatch which might indicate I'm doing something inappropriate. Now I think I might just be working with a slightly different bias: library as shared code, moreso than rigid code... which might be the assumption the OCaml build ecosystem is working with. I'm not developing/changing library code in a vacuum -- it's with respect to higher level usage and results. A reflection of the distinction between library use... the ossified libraries (rarely changed, system-wide) are used as packages, while libraries under active development as part of several apps are... not installed, and are included by "use_xxx" of ocamlbuild. Does this make sense? On Thu, Dec 12, 2013 at 3:33 PM, Gabriel Scherer wrote: > I'm not trying to dismiss your workflow, it's new=B9 to me and interestin= g. > 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 < > 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; inste= ad >> 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.cm= i'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 suggesti= on? >> >> 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 developme= nt >> too? Or does everyone work with libraries as explicitly built and >> separately installed units? (Note: I do have some slowly-evolving librar= ies >> 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, s= eem >> 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 >> >> > --047d7b62492c541b7704ed5f1c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The benefit is editing library code as freely as applicati= on code. If I have to do a separate build/install, and then build/install u= p the hierarchy, this becomes a significant pain if it's a bit of code = which I'm doing a edit/test cycle with.

For example, say I have some procedural noise function= (in noiselib) which I'm enhancing, with respect to a particular applic= ation (app), and we have this dependency: app > texturelib > noiselib= . I'd rather not have this process to iterate with:

<noiselib> make; make install_local
<noiselib> cd ../texturelib
<textur= elib> make clean; make; make install_local
<textureli= b> cd ../app
<app> make clean; make

Also note the "install_local" as opposed to "install"= -- this would be a minor ugliness too. I have applications which rely on m= ore stable versions of the libraries installed system-wide, and infrequentl= y updated. If I'm needing a special install process anyway, why install= at all? Seems better to use it in-place.

Creating an "app-local" version o= f the function in question (extending modules via include) can work, and I = do this, but sometimes the changes are more complex or pervasive than a sin= gle function -- and you don't always realize the changes are going to e= scape their initial scope.

I regularly develop libraries in parallel w= ith application code. This was also the case in the large studios I've = worked in (games). Typically there are a few tiers of library code -- where= a library is common code, rather than rigid code. In practice the library = code doesn't change much because other code depends on it and has fixed= the interfaces, but when you do work with library code, it's in the co= ntext of application and needs the benefit of easy edit/test iteration. I t= hink another view of libraries is much more standalone, with unit-tests to = determine correct behavior. Again, this can apply in some cases, but perhap= s it's less common with an interactive artsy application like games -- = where correctness is more a matter of end-result behavior, rather than some= thing you can build good unit-tests for.

Thank-you for asking, Gabriel... it helped = me sort some of this out for myself too! The stumbling blocks I'm encou= ntering have made me feel a bit uncertain -- there's an=A0impedance=A0m= ismatch which might indicate I'm doing something inappropriate. Now I t= hink I might just be working with a slightly different bias: library as sha= red code, moreso than rigid code... which might be the assumption the OCaml= build ecosystem is working with. I'm not developing/changing library c= ode in a vacuum -- it's with respect to higher level usage and results.=

A reflection of the distinction between lib= rary use... the ossified libraries (rarely changed, system-wide) are used a= s packages, while libraries under active development as part of several app= s are... not installed, and are included by "use_xxx" of ocamlbui= ld.

Does this make sense?


On Thu, Dec 12, 2013 at= 3:33 PM, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
I'm not trying to dismi= ss your workflow, it's new=B9 to me and interesting. But is there reall= y such a benefit to the "install-less" part of your setup? On the= project I've worked on, installation always took a time neglectible wh= en compared to compilation or (even more so) unit-testing. When you say &qu= ot;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 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.


On Thu, Dec 12, 2013 at 10:47 PM, An= thony 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



--047d7b62492c541b7704ed5f1c9c--