Re: [Caml-list] Packaging tool

[Xavier Leroy <xavier.leroy@inria.fr>]

> 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