Re: [Caml-list] a question about "ocamlopt" and "ocamldep"

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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
<virgile.prevosto@m4x.org> wrote:
> 2012/3/14 Matej Košík <5764c029b688c1c0d24a2e97cd764f@gmail.com>:
>
>> 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
>