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 6D91CBB9C for ; Wed, 30 Nov 2005 15:37:45 +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 jAUEbjEJ003153 for ; Wed, 30 Nov 2005 15:37:45 +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 PAA08519 for ; Wed, 30 Nov 2005 15:37:44 +0100 (MET) Received: from mail14.bluewin.ch (mail14.bluewin.ch [195.186.19.62]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jAUEbiOc009510 for ; Wed, 30 Nov 2005 15:37:44 +0100 Received: from [10.0.1.2] (83.78.44.68) by mail14.bluewin.ch (Bluewin 7.2.069.1) id 43853F0100148319 for caml-list@inria.fr; Wed, 30 Nov 2005 14:37:44 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20051130.211930.102965761.garrigue@math.nagoya-u.ac.jp> References: <438D6B4D.1070004@univ-savoie.fr> <20051130.211930.102965761.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4F70401E-AE91-4E5E-AF67-70FBDCC7C353@epfl.ch> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: How to compile different implementations of the same lib Date: Wed, 30 Nov 2005 15:38:05 +0100 To: caml-list X-Mailer: Apple Mail (2.746.2) X-Miltered: at concorde with ID 438DB939.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 438DB938.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 epfl:01 lib:01 cmx:01 cmi's:01 dependencies:01 inlining:01 cmx:01 inlining:01 lib:01 byte:01 debugging:01 -unsafe:01 cmi: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 30 nov. 05 =E0 13:19, Jacques Garrigue a =E9crit : > Note that with native code you must be careful to compile without any > .cmx around (only .cmi's), as this would induce dependencies on a > specific version. This also means that you lose inlining (one major > advantage of native code.) I don't understand this. Careful to compile what without which cmx =20 around ? And where do you lose inlining ? I recently got into the same kind of situation and I couldn't solve =20 it. So I'm seeking advice on how to solve the following the best way. =20= I want to give the choice between three implementation of a library =20 lib (which also calls C) in both byte and native code. 1. A debugging version compiled with -g, libdebug.cm(x)a. 2. A normal version, lib.cm(x)a 3. An unsafe version compiled with -unsafe and with some validation =20 of input parameters removed, libunsafe.cm(x)a. The input parameter validation code is centralized in a module Check. =20= This module has two implementation : one with the actual checks, and =20 the other with dumb checks equal to unit. Functions of the library =20 are implemented with this idiom : let f x =3D Check.arg x; ... The idea is to compile the unsafe version with the dumb =20 implementation of Check and that the optimizer will remove the calls =20 to the validation functions. My questions are, 1. Is it possible for all versions of this library to share the same =20 cmi interfaces ? When I tried to do this, I got these inconsistent =20 assumption errors. 2. For the unsafe version, will the calls to the Check functions be =20 removed by the optimizer ? My understanding is that they will but =20 only for native code compilation, i.e. libunsafe.cmxa. In =20 libunsafe.cma we will still have the function call overhead. Thanks for your help, Daniel