> to build a module, > you only need the *interfaces* of its dependencies, but it is unfortunately > not ensured when compiling to native code
It is actually possible to have separate compilation for .cmx, just like for .cmo: when ocamlopt looks for the .cmx for a given dependency, if it doesn't find it, it doesn't optimize, and doesn't record it as a dependency. So by selectively removing .cmx from your compilation environment, you can ensure to have only interface-dependency on some modules -- at the cost of disabled optimizations, of course. (I seem to remember that may happen in particular when you compile against certain libraries that do not distribute the .cmx separately.) > 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... Well, you could always recompile just before you want to link. What is usually called "link-time optimizations" are optimizations that are convenient to perform on the compiled objects directly (those that the linkers see). The high-level inlining or memory representation prediction optimizations are really part of "compilation" (but *when* you compile in the lifetime of your project is up to you; you could always distribute source only and compile just before running the program, without saving the result). On Tue, Mar 13, 2012 at 7:34 PM, Matthias Puech <pu...@cs.unibo.it> wrote: > 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? >> > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
