From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 691E5BC69 for ; Thu, 8 Mar 2007 08:05:05 +0100 (CET) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l28755jD031608 for ; Thu, 8 Mar 2007 08:05:05 +0100 Received: from [192.168.0.1] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp3-g19.free.fr (Postfix) with ESMTP id C8AAC81D5; Thu, 8 Mar 2007 08:05:04 +0100 (CET) Message-ID: <45EFB59F.2080902@inria.fr> Date: Thu, 08 Mar 2007 08:05:03 +0100 From: Alain Frisch User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Jakob Lichtenberg Cc: caml-list@inria.fr, Donn Terry Subject: Re: [Caml-list] Dependencies and rebuilding References: <43CD2D195487A448934920501C6EDB2303E342C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <43CD2D195487A448934920501C6EDB2303E342C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45EFB5A1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; frisch:01 frisch:01 dependencies:01 rebuilding:01 externally:01 recompile:01 trivial:01 cmx:01 dependencies:01 cmi:01 cmx:01 compilation:01 inlining:01 -for-pack:01 ocamlopt:01 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