Re: Policy, location of .cma files in binary packages, and dynlink...
Stefano Zacchiroli a écrit :
> The above distinction leaves out bytecode objects and native code
> objects; we currently ship both in libxxx-ocaml-dev. I find Stéphane
> reasoning convincing on the point that bytecode objects should be part
> of libxxx-ocaml. In a future where OCaml gains the capabilities of
> dynamically loading native code object probably also them should be
> moved from libxxx-ocaml-dev to libxxx-ocaml.
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.
> This leaves open an issue though. What about bytecode programs which
> uses OCaml libraries needing *.so stubs but *not* doing any dynamic
> loading of OCaml objects? The solution of moving *.cma to libxxx-ocaml
> will imply that all such applications will depend on a much bigger
> libxxx-ocaml containing stuff that won't be used. [...]
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...).
> [...] Does this justify an
> extra split of libxxx-ocaml in two packages: one containing just the
> *.so, the other containing bytecode objects? I'm not sure about that.
> [...]
> I'm not sure what the bottom line is. In principle the split you propose
> is the correct one, but basically we have just one package which benefit
> from it. Is it worth?
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
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)?
--
Stéphane
Reply to: