caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <Alain.Frisch@inria.fr>
To: Jakob Lichtenberg <jakobl@windows.microsoft.com>
Cc: caml-list@inria.fr, Donn Terry <donnte@windows.microsoft.com>
Subject: Re: [Caml-list] Dependencies and rebuilding
Date: Thu, 08 Mar 2007 08:05:03 +0100	[thread overview]
Message-ID: <45EFB59F.2080902@inria.fr> (raw)
In-Reply-To: <43CD2D195487A448934920501C6EDB2303E342C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>

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


  parent reply	other threads:[~2007-03-08  7:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-07 20:07 Jakob Lichtenberg
2007-03-07 21:24 ` [Caml-list] " Olivier Andrieu
2007-03-07 21:47   ` Jakob Lichtenberg
2007-03-07 21:25 ` Zheng Li
2007-03-08  7:05 ` Alain Frisch [this message]
2007-03-08 16:55   ` [Caml-list] " malc
2007-03-09  8:01     ` Alain Frisch
2007-03-09  8:06       ` malc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45EFB59F.2080902@inria.fr \
    --to=alain.frisch@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=donnte@windows.microsoft.com \
    --cc=jakobl@windows.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).