From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 86E8ABBAF for ; Fri, 21 May 2010 11:51:55 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnECANv09UtKfVK2mGdsb2JhbACdOl4IFQEBAQEBCAkMBxEirGuCAYUjLohOAQEDBYUNBA X-IronPort-AV: E=Sophos;i="4.53,277,1272837600"; d="scan'208";a="59789505" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail1-smtp-roc.national.inria.fr with ESMTP; 21 May 2010 11:51:55 +0200 Received: by wye20 with SMTP id 20so553486wye.27 for ; Fri, 21 May 2010 02:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eQ25rBdr9Lb7CxowVOlQ80kd7y/oA5PZ+9L0lbHy+f4=; b=sRYMfciGtwk4jNgjhXYOeLY5tPMGLihaBegm4jgaEWs9lTWEtts6KgcD1NaOM9bOjx K6pCCcIXv+/397Y8e1AmG8Z9KgjobR8D65qnGltH9EAFBR8b0OKcrNiVsC4PXIuNpJTN Bgn0ebi479QAnfoj4bWxBKg9ZDnPGpBevj5iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U6fHWd7IAHaAwjeRIUqF9U0EE5f3IXfpS3MUt3gF3eGvm0s+gZHx1Dv0nk/Ho3KjrS cYCIWdsPV7Q6Ozm/igqoFtr65gWspnvRPUoD3NF3OSpVJwdWkqkXsp5DA8qFBQptiSqM 2longcklVh2GwD3FtulhDOQ3vZ0Jek4Rx+r9Q= MIME-Version: 1.0 Received: by 10.216.155.196 with SMTP id j46mr673648wek.1.1274435514675; Fri, 21 May 2010 02:51:54 -0700 (PDT) Received: by 10.216.0.71 with HTTP; Fri, 21 May 2010 02:51:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 11:51:54 +0200 Message-ID: Subject: Re: [Caml-list] Private modules in packages From: Hans Ole Rafaelsen To: Julien Signoles , Michael.Grunewald@laposte.net Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=00163646cf3a2432f9048717a4e2 X-Spam: no; 0.00; rafaelsen:01 mli:01 foo:01 mli:01 foo:01 signoles:01 signoles:01 rafaelsen:01 -pack:01 compilation:01 cmi:01 plug-ins:01 makefiles:01 compilation:01 -pack:01 --00163646cf3a2432f9048717a4e2 Content-Type: text/plain; charset=ISO-8859-1 Thanks Michael and Julien, That did the trick. I manually inserted the content of the Bar.mli and Foo.mli into the P.mli file. Guess unless it is some way to include this automatically the best will be to write a script to generate the P.mli file automatically based on current version of Bar.mli and Foo.mli as part of the build process. -- Hans Ole On Fri, May 21, 2010 at 10:53 AM, Julien Signoles wrote: > Hello, > > 2010/5/21 Hans Ole Rafaelsen > > When packing a set of modules into a top module using -pack, is there a way >> to have some of the modules private to the package? >> >> If I have the modules Helper, Foo and Bar. Helper provides helper >> functions used by Foo and Bar. When I'm packing them into a top mudule P, I >> do not want to expose the functions of Helper to users of P. >> >> Is there some way to achieve this? If not, do anyone know of other ways >> for packing libraries and keeping some of the modules private to the >> library? >> > > Just write yourself a file p.mli without your private modules: > === p.mli === > module Foo : ... > module Bar : ... > ========== > Of course, you can not refer to signatures of modules Foo and Bar in p.mli. > Thus you have to duplicate them or, better, to write them somewhere outside > the package. > > From a compilation point of view, be sure to generate p.cmi by using p.mli > before generating the pack files p.cm[ox]. > > We use such a trick in the Frama-C tool (http://frama-c.com) for providing > (usually empty) interfaces of its plug-ins. But I do not recommend you to > read the Frama-C Makefiles for looking at the corresponding compilation > lines (except if you are **very** motivated). > > Hope this helps, > Julien > --00163646cf3a2432f9048717a4e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Michael and Julien,

That did the trick. I manually inserted t= he content of the Bar.mli and Foo.mli into the P.mli file. Guess unless it = is some way to include this automatically the best will be to write a scrip= t to generate the P.mli file automatically based on current version of Bar.= mli and Foo.mli as part of the build process.

--
Hans Ole

On Fri, May 21, 2010 = at 10:53 AM, Julien Signoles <julien.signoles@gmail.com> wrote:
Hello,

2010/5/21 Hans Ole Rafaelsen <= hrafaelsen@gmail.com>

When packing a set of modules into a top module using -pack, is there a way= to have some of the modules private to the package?

If I have the m= odules Helper, Foo and Bar. Helper provides helper functions used by Foo an= d Bar. When I'm packing them into a top mudule P, I do not want to expo= se the functions of Helper to users of P.

Is there some way to achieve this?=A0 If not, do anyone know of other w= ays for packing libraries and keeping some of the modules private to the li= brary?

Just write yourself a file p.mli with= out your private modules:
=3D=3D=3D p.mli =3D=3D=3D
module Foo : ...
module Bar : ...
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Of course, you can not refer to signatures of m= odules Foo and Bar in p.mli. Thus you have to duplicate them or, better, to= write them somewhere outside the package.

From a compilation point of view, be sure to generate p.cmi by using p.= mli before generating the pack files p.cm[ox].

We use such a trick in the Frama-C tool (http://frama-c.com) for provi= ding (usually empty) interfaces of its plug-ins. But I do not recommend you= to read the Frama-C Makefiles for looking at the corresponding compilation= lines (except if you are **very** motivated).

Hope this helps,
Julien

--00163646cf3a2432f9048717a4e2--