Re: [Caml-list] on the -pack option

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

> Is there a particular reason why ocamlmklib does not support the pack
> option ?

Well, basically because I think it wouldn't make much sense.
The job of ocamlmklib is to build a mixed C/Caml library, that is:
- a ".cma" Caml library
- a ".a" and/or ".so" C library
- the necessary annotations in the ".cma" so that the C part is
  automatically linked.

I feel that packing a set of Caml object files (.cmo) into
substructures of a single Caml object file (which is what -pack does)
is best done by a separate invocation of ocamlc -pack.  That is,
you can always do
        ocamlc -pack -o mylib.cmo a.cmo b.cmo c.cmo
        ocamlmklib -o mylib ... mylib.cmo

> Also, i have the feeling that the correct way of distributing a bunch of
> .cmo is to create a .cma, not to cram them together in a super .cmo
> thanks to the pack option, i may be wrong about this though.
> 
> The current documentation only gives an example of using the -pack
> option to build .cmos, not to build a .cma. Maybe such an example could
> be added, or at least a little notice about it ?

I agre with Chris' reply.  Maybe the docs should be clearer about
this, but basically a .cma is a set of .cmo, while -pack builds a
single .cmo from other .cmo.  Nothing prevents you from packing cmo's
into lib.cmo (ocamlc -pack -o lib.cmo ...), then building
lib.cma containing only lib.cmo (ocamlc -a -o lib.cma lib.cmo).
That might be useful if your lib also needs C code, as shown above.

> [about not linking unused code]
> BTW, if you pack the .cmos into a single .cmo and then put this one in a
> .cma, you should get the same benefit as what you describe, isn't it ?

Unfortunately not.  The .cma contains only one .cmo, which is either
not linked at all or linked in full.  For the bytecode compiler, it
could be possible to eliminate unused code with a finer grain.  But
for the native-code, we are severely constrained by what the Unix and
Win32 linkers know how to do, and they can only eliminate whole object
files, not parts of them.

For some libraries, this isn't really a problem: by design, you'll
generally use most of their modules.  For other libraries (e.g. Baire :-)
it's more problematic.  There is a delicate trade-off here between
selective linking and avoiding compilation unit namespace pollution.
I can't say I'm completely happy about this, but I'm afraid this is
the best we can do with the limited abilities of today's linkers.

> BTW, advi build fails on ia64

Yes, your bug report is in the database and will be addressed in due time.

- 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