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 7D65D7EE99 for ; Fri, 13 Dec 2013 04:34:01 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of stephen.magill@gmail.com) identity=pra; client-ip=74.125.82.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="stephen.magill@gmail.com"; x-sender="stephen.magill@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of stephen.magill@gmail.com designates 74.125.82.173 as permitted sender) identity=mailfrom; client-ip=74.125.82.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="stephen.magill@gmail.com"; x-sender="stephen.magill@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-we0-f173.google.com) identity=helo; client-ip=74.125.82.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="stephen.magill@gmail.com"; x-sender="postmaster@mail-we0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwDAGl/qlJKfVKtlGdsb2JhbAA/GoNCVaVliiSIUYEWCBYOAQEBAQcLCwkSKoIlAQEEAUABGxILAQMBCwYFCxohIgERAQUBChIGExKHXQEDCQgNNqYfjFqDCYQ6ChknAwpkhiYRAQUMjwYEB4Q2BIlDjlKBMI53GCmDGIFcHg X-IPAS-Result: AkwDAGl/qlJKfVKtlGdsb2JhbAA/GoNCVaVliiSIUYEWCBYOAQEBAQcLCwkSKoIlAQEEAUABGxILAQMBCwYFCxohIgERAQUBChIGExKHXQEDCQgNNqYfjFqDCYQ6ChknAwpkhiYRAQUMjwYEB4Q2BIlDjlKBMI53GCmDGIFcHg X-IronPort-AV: E=Sophos;i="4.95,476,1384297200"; d="scan'208";a="40816318" Received: from mail-we0-f173.google.com ([74.125.82.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Dec 2013 04:34:00 +0100 Received: by mail-we0-f173.google.com with SMTP id u57so1335529wes.18 for ; Thu, 12 Dec 2013 19:34:00 -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=fGUJ481oBPQRvjHeVJLnNdIXoXSHWz9RMRq8IKqw5yI=; b=wNarqrix3/MmhxrKO++MpNt9Ozu5R9vs0kHepyxfr2wv2nvQO0FMYOXdqijot42RU/ loNiey6JRvV3X/FwWB8SJnAqEG4kXhLem2s3VE86sv+OMeOYselmpwaXfPjnxoJfVqMk n62tlg9jfxgcCOVkN7uKIocqSRzY0KOLSKtX8nirlIEGawZdwRfeG09XdJLaK9G/QtXm EK9LFaUVYxeTY4+DlVyZDPAA7pfckwsGrHbkFwfqzWFvv6Cr48qXxfjLJLnrombq+d9V 4v637RxJTZ+S/lu89Ll0iKkgQpa1qE0/IZqiOnc/CKNb7U8bv4F+Q+RELsajxkYDVmbB 0D1A== MIME-Version: 1.0 X-Received: by 10.180.36.40 with SMTP id n8mr981022wij.54.1386905640291; Thu, 12 Dec 2013 19:34:00 -0800 (PST) Received: by 10.194.140.16 with HTTP; Thu, 12 Dec 2013 19:34:00 -0800 (PST) In-Reply-To: <3029652948434D5A8C48531553154776@erratique.ch> References: <3029652948434D5A8C48531553154776@erratique.ch> Date: Thu, 12 Dec 2013 22:34:00 -0500 Message-ID: From: Stephen Magill To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: Anthony Tavener , Gabriel Scherer , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=e89a8f5030d206d32d04ed622217 Subject: Re: [Caml-list] A way to avoid "WARNING: myocamlbuild.cmi occurs in several directories"? --e89a8f5030d206d32d04ed622217 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a similar development setup and have made effective use of ocp-build to enable a tight development loop while still supporting opam deployment. Suppose you have libraries A and B and a program P that uses these, each in their own directory (or repository). You set these up with a per-project .ocp file that describes the library / program sources and a per-project Makefile. For each project X, the Makefile (or OPAM build rules) executes: ocp-build init ocp-build configure ocp-build X This configures ocp-build to only search in that directory when doing its build. When doing development, you skip the per-project makefiles and instead arrange things as: projects/A projects/B projects/P And you execute the "ocp-build init; ocp-build configure" portion in the *projects* directory. This sets "projects" as the ocp-build root directory and causes ocp-build to find all the per-project .ocp files. The dependencies between the program and libraries will be properly resolved and even if you have A or B installed with findlib, the local versions of the libraries will take precedence when building / linking P. Just compile P with "ocp-build P" (executed somewhere in the projects/ directory tree). You do have to be careful to ensure that during development you never accidentally create a "projects/X/_obuild" directory (e.g. you never accidentally invoke "make" in any of the project directories). ocp-build will stop at the first _obuild directory it finds, so having _obuild directories other than projects/_obuild will prevent the full traversal of the projects/* subdirectories. --Stephen On Thu, Dec 12, 2013 at 7:12 PM, Daniel B=FCnzli wrote: > > > Le vendredi, 13 d=E9cembre 2013 =E0 00:57, Anthony Tavener a =E9crit : > > > I regularly develop libraries in parallel with application code. > > Since you seem to be using ocamlbuild, at a certain point I was using (and > still use sometimes) a workflow that I described here: > > > http://brion.inria.fr/gallium/index.php/Working_on_dependent_projects_wit= h_ocamlbuild > > If you work with version control you could also make local git package for > the libs. That way you can update your all your libraries after new commi= ts > with a single `opam update && opam upgrade`. > > Best, > > Daniel > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --e89a8f5030d206d32d04ed622217 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have a similar development setup and have made effective= use of ocp-build to enable a tight development loop while still supporting= opam deployment. =A0Suppose you have libraries A and B and a program P tha= t uses these, each in their own directory (or repository). =A0You set these= up with a per-project .ocp file that describes the library / program sourc= es and a per-project Makefile. =A0For each project X, the Makefile (or OPAM= build rules) executes:
=A0 ocp-build init
=A0 ocp-build configure
=A0 ocp-buil= d X

This configures ocp-build to only search in th= at directory when doing its build. =A0When doing development, you skip the = per-project makefiles and instead arrange things as:
=A0 projects/A
=A0 projects/B
=A0 projects/P
=

And you execute the "ocp-build init; ocp-build con= figure" portion in the *projects* directory. =A0This sets "projec= ts" as the ocp-build root directory and causes ocp-build to find all t= he per-project .ocp files. =A0The dependencies between the program and libr= aries will be properly resolved and even if you have A or B installed with = findlib, the local versions of the libraries will take precedence when buil= ding / linking P. =A0Just compile P with "ocp-build P" (executed = somewhere in the projects/ directory tree). =A0You do have to be careful to= ensure that during development you never accidentally create a "proje= cts/X/_obuild" directory (e.g. you never accidentally invoke "mak= e" in any of the project directories). =A0ocp-build will stop at the f= irst _obuild directory it finds, so having _obuild directories other than p= rojects/_obuild will prevent the full traversal of the projects/* subdirect= ories.

--Stephen

On Thu, Dec 12, 2013 at 7:12 PM, Daniel B=FCnzl= i <daniel.buenzli@erratique.ch> wrote:


Le vendredi, 13 d=E9cembre 2013 =E0 00:57, Anthony Tavener a =E9crit :

> I regularly develop libraries in parallel with application code.

Since you seem to be using ocamlbuild, at a certain point I was using= (and still use sometimes) a workflow that I described here:

http://brion.inria.fr/gallium/inde= x.php/Working_on_dependent_projects_with_ocamlbuild

If you work with version control you could also make local git package for = the libs. That way you can update your all your libraries after new commits= with a single `opam update && opam upgrade`.

Best,

Daniel



--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
<= br>
--e89a8f5030d206d32d04ed622217--