From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA20583; Thu, 3 Jan 2002 15:15:49 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA20546 for ; Thu, 3 Jan 2002 15:15:48 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g03EFkb01539; Thu, 3 Jan 2002 15:15:46 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA20526; Thu, 3 Jan 2002 15:15:46 +0100 (MET) Date: Thu, 3 Jan 2002 15:15:46 +0100 From: Xavier Leroy To: Ohad Rodeh Cc: caml-list@inria.fr Subject: Re: [Caml-list] Packaging tool Message-ID: <20020103151546.C19606@pauillac.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from ORODEH@il.ibm.com on Thu, Nov 29, 2001 at 10:39:03AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > There have been long discussions on the list about packaging. > I have a relatively simple suggestion; which we currently use in our system > (Ensemble). I think people have suggested something similar in the > past, though I felt the discussion got sidtracked. > > Suppose you have a list of modules: A, B, C, and you which to > package them in a module X. What I would like to do, regardless of > how A, B, and C were compiled and whether they are directories or > not, is to package them in a module X. This would allow an > application that link with a library containing A B and C to write: > > open X > ..... > A.f 1 2; > B.g "adsf" "xxx"; > etc. I agree this would be nice. It seems to be the most natural way to package OCaml modules into a hierarchy. A tool to do this has been on my to do list for a while. However, we hit some practical problems with the native-code compiler (see below). > Such an automatic tool does not exist for Caml yet, so we wrote > something simple our self (credit goes to Mark Hayden). What the > tool does is to take modules A, B, and C, and create a file named > X.ml that looks like this: > > module A = A > module B = B > module C = C > > Then, a library (X.cma, or X.cmxa) containing A,B,C is created, and > applications can then work as above. > This suffices for us, however, there is a caveat: an application > using the library can also simply use A without the X, so that if A > contains type t, then X.A.t and A.t are both legal. Right. Moreover, this doesn't solve the namespace pollution problem. The X.cmi file still refers to the toplevel modules A, B, C, meaning that A.cmi, etc, must still be around. Similarly, at link-time global variables corresponding to the toplevel modules A, B, C are created, meaning that you can't have another toplevel module named A, B, or C in your program. To work around this, we'd need to: 1- Synthesize a signature X.cmi for X that does not refer to A.cmi, etc. This is fairly easy to do. 2- Generate an object file X.cmo or X.cmx/X.o that does not define the global variables A, B, C. The easiest way to do this (without recompiling the source files for A, B and C, of course!) is to rename those global variables into, say, X.A, X.B, X.C. No big deal for the bytecode compiler. But for the native-code compiler, we need the ability to rename a symbol from a native object file. And I haven't yet found a way to do this with standard tools, neither under Unix nor Windows! (Under Unix, the GNU binutils and the BFD library come close to allowing this, but not quite.) > I'd like such a tool to be standard (part of Caml), as it is simple > enough and does not force the developer to take any design decisions > that he is not willing to take. So do I, but I'm stuck with the renaming problem above. - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr