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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 22F0BBB9C for ; Mon, 5 Dec 2005 15:00:12 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB5E0BX8024530 for ; Mon, 5 Dec 2005 15:00:11 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA20565 for ; Mon, 5 Dec 2005 15:00:11 +0100 (MET) Received: from mail13.bluewin.ch (mail13.bluewin.ch [195.186.18.62]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jB5Dxo0t012362 for ; Mon, 5 Dec 2005 15:00:11 +0100 Received: from [10.0.1.2] (81.62.71.117) by mail13.bluewin.ch (Bluewin 7.2.069.1) id 438B1A90001C67BF for caml-list@inria.fr; Mon, 5 Dec 2005 13:59:50 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20051205114622.GB6870@furbychan.cocan.org> References: <33E57BD4-F484-4E0B-8B23-DC84D4A3061E@epfl.ch> <20051205114622.GB6870@furbychan.cocan.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3C5A94D7-998F-4BE4-BC27-C6DDAC3C2620@epfl.ch> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Checking an interface against an implementation Date: Mon, 5 Dec 2005 15:00:15 +0100 To: caml-list X-Mailer: Apple Mail (2.746.2) X-Miltered: at concorde with ID 439447EB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 439447D6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 epfl:01 caml-list:01 cmi's:01 cmo:01 cmi:01 cmi:01 cmo:01 mylib:01 mylib:01 mli:01 mli:01 defines:01 sig:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Le 5 d=E9c. 05 =E0 12:46, Richard Jones a =E9crit : > I think the tool you're looking for is "objinfo" -- on Linux it's > usually installed as "ocamlobjinfo". However this tool only works on > .cmi's or .cmo's, not .cmx's. Thanks for the info (however note that this tool doesn't seem to be =20 installed by default, at least if you compile from the source). However I think what I want to do is impossible, apparently cmo =20 record the cmi they were compiled with (in my case the one =20 automatically generated) and refuse to link if the client was =20 compiled with a different cmi. In other words a .cmo can have only =20 one .cmi, is that true ? One way to achieve what I want is to do the following mylib/a.ml mylib/b.ml mylib/mylib.ml mylib/mylib.mli Such that mylib.ml is : module A =3D A module B =3D B and mylib.mli defines the constrained interfaces : module A =3D sig ... end module B =3D sig ... end But I have the following two questions. Suppose I pack the objects =20 files into a cma and cmxa, 1) Is there any performance impact when the client uses functions =20 from A or B via Mylib ? Does it introduce an indirection ? 2) Don't I lose the benefit of cm(x)a ? I have the impression that =20 here, even if the client uses only functions from Mylib.A, b.cmo (or =20 b.cmx) will also be linked in. Is that right ? Daniel =20 =20=