Indeed, ocamlc is faster than ocamlopt (because there is less analysis in the backend, and simply less work to do to bridge the expressivity gap) and suited for fast compile-and-edit cycles.
There are occasional cases when I've seen a use for ocamlopt, when I needed to integrate a "run automated tests" in my feedback loop, and some tests where noticeably faster when natively compiled. I must admit I have never give a thought to the .cmx handling, as that has never appeared to be an issue in the past. I'm not sure how hard it is to integrate a "no .cmx dependency" pass in the Makefile; intuitively, just doing "mv *.cmx cmx_save_dir/" before each compilation command ought to be enough. It might be interesting to add a "don't depend on .cmx" option to the compiler, so that it's only a flag to add somewhere in your build system. Given the existence of ocamlc, there is few incentive for this, and apparently the OCaml maintainers have not considered it high-priority. See the following bug report (and do not hesitate to comment there if you are sure that, indeed, you have a real need for this feature): http://caml.inria.fr/mantis/view.php?id=4389 The following bug report is also related to .cmx/.cmxa and implementation dependency (short story: if as a library provider you want your users to be able to cross-optimize with the library code, providing .cmxa is not enough, you also have to provide the separate .cmx): http://caml.inria.fr/mantis/view.php?id=4772 On Wed, Mar 14, 2012 at 2:19 PM, Virgile Prevosto <[email protected]> wrote: > 2012/3/14 Matej Košík <[email protected]>: > >> There are two scenarios when I use the compiler: >> >> Scenario 1 (most frequent): when I want to incrementally remove typing >> errors during development. Various optimizations do not matter here. >> What matters is a short time to rebuild everything (that has to be rebuilt). >> >> Scenario 2 (rare one): to produce the final product >> where quality of various optimizations matter more than >> the amount of required compilation time >> >> If dropping dependencies of *.cmx files on other *.cmx files (rather >> than on *.cmi files) requires manual intervention or careful thinking, >> then ocamlopt, with this behavior, is not ideal tool for Scenario 1 >> (while still being perfectly suitable for Scenario 2). > > Scenario 1 is exactly what bytecode compilation is for, and it is > indeed fast and without dependencies on .cmo. > > > > > > -- > E tutto per oggi, a la prossima volta > Virgile > > > -- > 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
