[Caml-list] Packaging tool

[Caml-list] Packaging tool

[Ohad Rodeh]

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.

you get the picture.

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.

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. I
also wonder how the above problem can be
fixed.

   thoughts?

   Ohad.

PS
    The tool can be found in ensemble/tools/emrg.ml+mkutil.ml, it also
merges the .mli files: A.mli, B.mli, C.mli, with
the documentation, so that X.mli contains all the documentation of your
library.


-------------------
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

Re: [Caml-list] Packaging tool

[Xavier Leroy]

> 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

Re: [Caml-list] Packaging tool

[malc]

On Thu, 3 Jan 2002, Xavier Leroy wrote:

> 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.)

Actually piece of cake with ELF/GNU binutils, consider this:
(file a.s)
.globl A
A: nop
<eof>

(file retain)
X_A
<eof>

rename$ as -o a.o a.s 
rename$ nm a.o
00000000 T A
rename$ ld -r -o x_a.o --defsym X_A=A a.o --retain-symbols-file retain
rename$ nm x_a.o 
00000000 T X_A

-- 
mailto:malc@pulsesoft.com

-------------------
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

Re: [Caml-list] Packaging tool

[Dmitry Bely]

malc <malc@pulsesoft.com> writes:

> > 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.)
> 
> Actually piece of cake with ELF/GNU binutils, consider this:
> (file a.s)
> .globl A
> A: nop
> <eof>
> 
> (file retain)
> X_A
> <eof>
> 
> rename$ as -o a.o a.s 
> rename$ nm a.o
> 00000000 T A
> rename$ ld -r -o x_a.o --defsym X_A=A a.o --retain-symbols-file retain
> rename$ nm x_a.o 
> 00000000 T X_A

As for Windows, it really seems that there is no an equivalent tool in
MSVC distribution. But fortunately both MSVC and gcc/Win32 use the same COFF
format for object files, so one can use Cygwin or MinGW-compiled binutils
to hack MSVC-produced files (can be taken from www.cygwin.com or
www.mingw.org). Not very elegant, but it should work.

Hope to hear from you soon,
Dmitry


-------------------
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

[Caml-list] Packaging tool

[Ohad Rodeh]

Following the short discussion on packing, I've found the time to hack on
it a little bit, the results can be found at:
      http://www.cs.cornell.edu/Info/Projects/Ensemble/mrg/doc.html

In brief, this a Caml packaging tool that works!

Comments are welcome,
     Ohad.


-------------------
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