[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy, location of .cma files in binary packages, and dynlink...



On Mon, Jan 21, 2008 at 09:48:18PM +0100, Stéphane Glondu wrote:
> I see OCaml's dynamic loading it this way: in the native world, .cmxs
> would be like .so (dynamic linking), and .cmx/.a/.cmxa would be like
> .o/.a (static linking). In the bytecode world, .cmo/.cma play a role in
> both kinds of linking.

What do you mean with "I see ... this way"? Is that what you would like
to see in the forthcoming future or what? Assuming so, why are you
differentiating the final effects of native and bytecode objects?
Ideally, everything should be linkable dynamically and that should be
done per default; then, if one really wants, it should be possible to
statically link, but I would like to see this possibility both for
native and bytecode world.

> And what about programs which do dynamic loading? With the current
> scheme, they formally depend on the libxxx-ocaml-dev package which may
> have a lot more stuff that won't be used (.mli, .cmi, developer's doc...).

This point was addressed by the remainder part of my post, I believe.

> I did not think about putting dynlinkable objects in another package.
> Why not. But what about the native/bytecode duality for dynlinkable
> objects that there will soon be? I think whatever choice you do, there

Uhm, any pointers that this will actually be the case? I'm aware of some
works in that direction, but I'm still missing hints that any of them
will be integrated in OCaml mainline.

If this is going to happen anytime soon (say OCaml 3.11) we should maybe
change our splitting policy once and for all, pro-actively taking into
account that.

> will always be some unused file in some package. So putting dynlinkable
> objects directly in libxxx-ocaml is not so shocking IMHO. If we decide
> nethertheless to create some separate package for dynlinkable objects,
> maybe we could just enforce the usage of native dynlink if available...
> Is there some reason why one would like both bytecode AND native
> versions of end-user libraries/programs (besides of dynlink and toplevel
> convenience)?

There still are for some old hardware, where native code stuff used to
took much more time to load; this was, for example, a reason for the
existence of ocaml-native-compilers. Of course such kind of motivations
fade more and more with passing years.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Attachment: signature.asc
Description: Digital signature


Reply to: