From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 33A20820A1 for ; Fri, 6 Sep 2013 17:28:36 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.90,855,1371074400"; d="scan'208";a="31818558" Received: from dhcp-rocq-250.inria.fr (HELO [128.93.62.250]) ([128.93.62.250]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 06 Sep 2013 17:28:35 +0200 Message-ID: <5229F4A0.40606@inria.fr> Date: Fri, 06 Sep 2013 17:28:32 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Gabriel Scherer CC: "caml-list@inria.fr" References: <5229DEF9.7040706@inria.fr> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] Accelerating compilation Le 06/09/2013 17:18, Gabriel Scherer a écrit : > Those are all good points, but they would be just as appropriate as > feature requests in the OCaml bugtracker ( > http://caml.inria.fr/mantis/ ). Actually Xavier Clerc noticed me that there is already a related feature request: http://caml.inria.fr/mantis/view.php?id=6102 > I think it should not be too difficult to add a flag to the compiler > to only produce .cmi files out of its source inputs, and not also a > .cmo (or also a .cmx) as is currently done. If you (or anyone > interested in contributing) are interested in providing a patch for > this, I'm more than ready to review the patch to help upstream > integration. I'd consider this "junior job" difficulty. Thanks for your review proposal. I might actually consider doing this the day it becomes too much of a pain. FR#6102 actually have a patch attached which looks like a nice starting point. > > Integrating this into build systems may be trickier because, as Markus > noted, just asking for the .cmi of the main module of your project > will recursively build .cmi from the .mli of its dependencies, without > checking that the .ml matches them. You could add a phony rule/stamp > .impl.cmi that is handled differently by the build system (basically > like .cmo, except they would be empty). > > Your points (2) and (3) are well noted. I've personally been thinking > about an optional -use-timestamp option for ocamlbuild, but devoted my > own contribution time to other things this summer. > > > Markus Mottl wrote: >> I'm not sure what you are referring to, OCamlBuild does already >> support parallel builds. > > While there is support for parallel compilation in ocamlbuild (... > except on Windows, I'm afraid), I've often found out that it doesn't > parallelize much in practice because of current implementation > limitations -- but if you have success stories about this I'd be glad > to hear about them. Improving on this is on the medium-term > ocamlbuild-development TODO list. > > On Fri, Sep 6, 2013 at 3:56 PM, Romain Bardou wrote: >> Hello list, >> >> As my project grows bigger, it is becoming much less efficient to use >> the type-checker to quickly find places in my code which must be updated >> (e.g. pattern-matching). Here is a wishlist for improvements. >> >> 1) Separate typing and code generation, in ocamlc and in ocamlopt >> >> For instance, provide an option -typing-only which would mean "only >> produce the .cmi but do not produce the .cmo or the .cmx". The compiler >> would only need the .cmi of the dependencies, not their .cmo or .cmx. >> This would make it possible to have a Makefile target, or an Ocamlbuild >> option, to just type. >> >> Also, provide an option -do-not-retype which would mean "if the .cmi >> exists, load it instead of type-checking again". This would allow the >> build process to first type-check (using -typing-only) and then generate >> the code without type-checking again (using -do-not-retype). Of course >> the build system should be very careful to ensure the .cmi is >> up-to-date. This option could also help when compiling both in bytecode >> and in native code. This option is not necessary to just find errors >> quickly, though. >> >> 2) Be able to disable Ocamlbuild's digest mechanism and use dates and >> file sizes instead >> >> If I am not mistaken, this is one of the main reasons why Ocamlbuild is >> slower that make. It does help to prevent useless recompilation, but >> what good does it make to prevent a useless recompilation once in a >> while if it is at the cost of losing a lot of time in all other cases? >> I'm sure it is project-dependent though so it should only be an option, >> say, -do-not-hash, or -comparison-mode dateandsize. >> >> 3) Parallel compilation in Ocamlbuild >> >> Of course it would help but it is not easy to implement so I'm just >> putting it there to be exhaustive. >> >> I think the most important point is the first one, as the other two >> depend on the build system, and they have been debated already. I'm not >> aware of any discussion about separing typing and code generation >> though. What do you think about that? >> >> Cheers, >> >> -- >> Romain Bardou >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >