Re: [Caml-list] a hard road to a new toplevel

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

> and try to make a new toplevel, which would have access to a module I'm
> interested in: Unix2. I started from 
> 
> ocamlmktop unix2.cmo -o unix2top
> 
> and subsequently added more and more modules to the absence of which it
> complained. It took not less than one hour of trials. Resulting in this:
> 
> ocamlmktop string2.cmo file.cmo str.cma netstring_str.cmo
> netencoding.cmo base64.cmo debug.cmo unix.cma timeout.cmo log.cmo
> unix.cma concur.cmo bufrw.cmo activebuffer.cmo str.cma unix.cma 
> /usr/lib/ocaml/select.o /usr/lib/ocaml/libunix2_c.a string2.cmo
> filename2.cmo printexc2.cmo sys2.cmo unix2.cmo netstring_str.cmo
> netencoding.cmo network.cma unix2.cmo -o unix2top
> 
> What did I do wrong? It is possible to get a transivite closure of all
> these dependencies in one shot?

Library files (.cma files) provide an answer to this issue: *if* the
authors of the library did a good job, they built a .cma file that
groups all .cmo files for their library, in the right order.  Then,
the final user simply links with the .cma file, and the OCaml linker
picks only the relevant .cmo files from the .cma.

If all you have initially is a bunch of .cmo files with no docs, then
I agree you run into the problem you describe.

> BTW the last step were purely gcc/ld
> dependecies on select.o and libunix2_c.a and there is now way to
> indicate libraries in the Unix style via -lLIB.

Not true:  -cclib -lunix2_c will pass a "-lunix2_c" option to gcc and ld.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners