Version française
Home     About     Download     Resources     Contact us    
Browse thread
Dependencies and rebuilding
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alain Frisch <Alain.Frisch@i...>
Subject: Re: [Caml-list] Dependencies and rebuilding
Jakob Lichtenberg wrote:
> If I change the body of functions in a base library, but not the
> externally visible signature, I still have to recompile the consumers of
> the base library prior to linking the main application.  While this is
> not a problem in the trivial case I'll show beneath, it may be a concern
> from a componentization and scalability point of view.  Regular C code
> does not have this limitation.  This e-mail to request why the design is
> as it is?

A .cmx file basically contains information:
- for the linker, most importantly dependencies information (md5 of .cmi
and .cmx used to compile them);
- for the compilation of other units which refer to this unit:
cross-module optimization information (linker symbols for direct
function calls, inlining).

A .cmx file also contains the information needed to compile against
*and* link with a unit compiled with -for-pack.

Note that the real object code is not found in the .cmx file, but in the
corresponding .o/.obj/... file.

When ocamlopt compiles a file b.ml which refers to a module A, it must
be able to find a.cmi (as with ocamlc), and it will also look for a.cmx.
If it cannot find a.cmx, then compilation will still succeed (without
cross-module optimization), but linking against A will fail if A had
been compiled with -for-pack. If you don't use -for-pack, you can
achieve the level of separate compilation you want by hiding .cmx files
to the compiler.

Libraries (.cmxa + .a/.lib) provide a convenient way to:
- mention a single file on the linker command line instead of many .cmx
files;
- let the linker figure out which units in the library are really needed;
- add C linker options (e.g. extra C objects/libraries to link with);
- combine many .o/.obj files together (but you still need the .cmi files
for "public" modules).

Libraries files are only used by the linker, and never by the compiler.
You can still provide the .cmx files in addition to the .cmxa file if
you want to enable cross-module optimization, and you have to provide
them if some public modules in the library have been compiled with
-for-pack.


-- Alain