[OASIS-devel] Cross-module inlining fails

[Markus Mottl]

On Mon, Nov 19, 2012 at 1:16 PM, Sylvain Le Gall <sylvain at le-gall.net> wrote:
> Second thought on this, exposing .cmx in a packed library is dangerous.
> Because single compilation are supposed to be accessed using Foo.Util, where
> foo is the pack. If you expose utils.cmx you will cause compilation errors
> for programs that uses themself module Utils. So exposing .cmx of a pack is
> kind of the contrary to what pack has been designed for. But maybe i miss
> something here.

Lets consider an example.  Lets assume you want to pack modules A and
B into a packed library module Foo.  Compiling A and B will generate
"a.cmx" and "b.cmx".  Packing A and B into Foo will then generate a
file "foo.cmx".  This "foo.cmx" file should be installed along with
the "foo.cmi", "foo.cmxa", and "foo.a" file after library creation.
It contains the information required for cross-module inlining.

Neither "a.cmx" nor "b.cmx" should be installed, because the user
cannot access these in their code if only "foo.cmi" (rather than
"a.cmi" and "b.cmi") is visible, as it should be.

So the resulting contents of the installation directory is: foo.cmi,
foo.cmx, foo.cmxa, foo.a.

Note that "foo.a" contains the machine code of the non-inlined
functions, whereas "foo.cmxa" only tells the linker how to resolve
calls to this code.  "foo.cmx", however, contains a code
representation suitable for inlining during compilation of other
modules.  It is entirely possible that linking with the ".cmxa" and
".a" file is basically a no-op for your program, because it may have
gotten all it needs from the ".cmx" file during compilation and
inlined it.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl at gmail.com