From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2DIZ8iu002532
	for <caml-list@sympa-roc.inria.fr>; Tue, 13 Mar 2012 19:35:08 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EACqTX0+CiAFmgWdsb2JhbABDhTqtKoMHIgEBFiYnggoBBSMPAQVAARAJAhoCBRYLAgIJAwIBAgFFEwEHAQGIBqoQkhSBL4wUggyBFgSoWQ
X-IronPort-AV: E=Sophos;i="4.73,578,1325458800"; 
   d="scan'208";a="149162053"
Received: from leb.cs.unibo.it ([130.136.1.102])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 13 Mar 2012 19:34:39 +0100
Received: from ssl.cs.unibo.it (ssl.cs.unibo.it [127.0.0.1]) (Authenticated sender: hidden)
	by leb.cs.unibo.it (Postfix) with ESMTPSA id EF626255A ;
	Tue, 13 Mar 2012 19:34:38 +0100 (CET)
Message-ID: <4F5F9342.4030104@cs.unibo.it>
Date: Tue, 13 Mar 2012 19:34:42 +0100
From: Matthias Puech <puech@cs.unibo.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: caml-list@inria.fr
CC: 5764c029b688c1c0d24a2e97cd764f@gmail.com
References: <4F5F8FBD.5060205@gmail.com>
In-Reply-To: <4F5F8FBD.5060205@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Caml-list] a question about "ocamlopt" and "ocamldep"

Hello,

This is consistent with how ocamlc/ocamlopt work: separate compilation 
is ensured the way you think by bytecode .cmo compilation: to build a 
module, you only need the *interfaces* of its dependencies, but it is 
unfortunately not ensured when compiling to native code, because of the 
global (inter-modules) optimizations performed (inlining AFAIK). Thus, 
to build a .cmx module, you need to be aware of the actual *code* of its 
dependencies.

I wonder now if it would be theoretically possible to do these 
optimization, not at compile-time, but delay them until link-time, when 
the code is fully known...

Cheers,
     -m

Le 03/13/2012 07:19 PM, Matej Košík a écrit :
> Hi,
>
> The "ocamldep" tool generates Makefile dependencies for both situations:
> - when we use "ocamlc"
> - as well as when we use "ocamlopt"
>
> Dependencies, generated for "*.cmo" files,
> are corresponding "*.cmi" files.
>
> This is not surprising.
>
> However, dependencies, generated for "*.cmx" files,
> are always other "*.cmx" files.
>
> This is surprising.
>
> Why "*.cmx" files do not depend on "*.cmi" files?
>
> I have noticed this in a bigger project but this phenomenon appear to
> happen for arbitrarily small projects.
>
> Consider the following ocamldep-generated couple of rules:
>
> src/ml2c/typing/printtyp.cmo: src/ml2c/typing/types.cmi \
>      src/ml2c/typing/primitive.cmi src/ml2c/typing/predef.cmi \
>      src/ml2c/typing/path.cmi src/ml2c/typing/outcometree.cmi \
>      src/ml2c/typing/oprint.cmi src/ml2c/utils/misc.cmi \
>      src/ml2c/parsing/longident.cmi src/ml2c/typing/ident.cmi \
>      src/ml2c/typing/env.cmi src/ml2c/typing/ctype.cmi \
>      src/ml2c/utils/clflags.cmi src/ml2c/typing/btype.cmi \
>      src/ml2c/parsing/asttypes.cmi src/ml2c/typing/printtyp.cmi
> src/ml2c/typing/printtyp.cmx: src/ml2c/typing/types.cmx \
>      src/ml2c/typing/primitive.cmx src/ml2c/typing/predef.cmx \
>      src/ml2c/typing/path.cmx src/ml2c/typing/outcometree.cmx \
>      src/ml2c/typing/oprint.cmx src/ml2c/utils/misc.cmx \
>      src/ml2c/parsing/longident.cmx src/ml2c/typing/ident.cmx \
>      src/ml2c/typing/env.cmx src/ml2c/typing/ctype.cmx \
>      src/ml2c/utils/clflags.cmx src/ml2c/typing/btype.cmx \
>      src/ml2c/parsing/asttypes.cmx src/ml2c/typing/printtyp.cmi
>
> The second rule seems to be unnecessarily demanding (unless it makes no
> sense to compile *.cmi files if we use ocamlopt). It should read:
>
> src/ml2c/typing/printtyp.cmx: src/ml2c/typing/types.cmi \
>      src/ml2c/typing/primitive.cmi src/ml2c/typing/predef.cmi \
>      src/ml2c/typing/path.cmi src/ml2c/typing/outcometree.cmi \
>      src/ml2c/typing/oprint.cmi src/ml2c/utils/misc.cmi \
>      src/ml2c/parsing/longident.cmi src/ml2c/typing/ident.cmi \
>      src/ml2c/typing/env.cmi src/ml2c/typing/ctype.cmi \
>      src/ml2c/utils/clflags.cmi src/ml2c/typing/btype.cmi \
>      src/ml2c/parsing/asttypes.cmi src/ml2c/typing/printtyp.cmi
>
> Shouldn't it?
>