From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2EHCtI1017035 for ; Wed, 14 Mar 2012 18:12:55 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYCANPQYE/RVdK2kWdsb2JhbAApGoU6nxWRVwgiAQEBAQkJDQcSKYIJAQEBBBICDx0BGxILAQMMBgMCCw0CAgkdAgIhAQERAQUBChIGEwgKEIdoCymdFgqLREyCcYUsP4h0AQULgSSIG4YegRYElVaLLoMbPYQJ X-IronPort-AV: E=Sophos;i="4.73,584,1325458800"; d="scan'208";a="136083193" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Mar 2012 18:12:49 +0100 Received: by iahk25 with SMTP id k25so4240254iah.27 for ; Wed, 14 Mar 2012 10:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Q7xEpCHlpL2BGf/MEp12zJTMEIHz6HQLzjvsmX2n3ns=; b=koOHyv614J4OU1HLmPB5brpsCXMNzDEnII4oj0f+YCAwicDAB5vrjPN3usUmRr41UZ 9EgqwP1ZyngANN4g7PK8NdfGC7LoAvDvZwu7g58hyACEweOAE1FZWNVneToby52n7X+y nJI/AfFh9o3w9LSenaNsAM9qVnDeUq87L9LvxJhhg5FpkUwWkrXkiDlc+k0rGT7dVE/D E9gBS515DaAr5xGZUVU0Av6dH2VHDMkXj9A3imLGJe3VICQbk1JC8uSM5/PONgF4Na1v 4asoTV3maJh7B4GufMSXcY3k1FeqydzBkiMj7ftXhpUzm/zwiqiBBGn4y4BunhONvO3M wDOQ== Received: by 10.50.180.135 with SMTP id do7mr5711123igc.56.1331745167848; Wed, 14 Mar 2012 10:12:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.3.38 with HTTP; Wed, 14 Mar 2012 10:12:07 -0700 (PDT) In-Reply-To: References: <4F607390.5040705@gmail.com> <4F609153.5040000@gmail.com> From: Gabriel Scherer Date: Wed, 14 Mar 2012 18:12:07 +0100 Message-ID: To: Virgile Prevosto Cc: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2EHCtI1017035 Subject: Re: [Caml-list] a question about "ocamlopt" and "ocamldep" 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 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 >