From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 268B4820A1 for ; Fri, 6 Sep 2013 17:19:20 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.41 as permitted sender) identity=mailfrom; client-ip=209.85.214.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f41.google.com) identity=helo; client-ip=209.85.214.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIBABDxKVLRVdYpk2dsb2JhbABbgzxRrw+SRoEcCBYOAQEBAQcLCwkUBCSCJAEBBUABGxICCQEDDAYFCw0NISIBEQEFAQoSBhMICoddAQMPDKBhjFCDBYQNChknAwpkiAwBBQyPcAeEHQOXdYEviwuDQxgphEo6 X-IPAS-Result: AnIBABDxKVLRVdYpk2dsb2JhbABbgzxRrw+SRoEcCBYOAQEBAQcLCwkUBCSCJAEBBUABGxICCQEDDAYFCw0NISIBEQEFAQoSBhMICoddAQMPDKBhjFCDBYQNChknAwpkiAwBBQyPcAeEHQOXdYEviwuDQxgphEo6 X-IronPort-AV: E=Sophos;i="4.90,855,1371074400"; d="scan'208";a="25979773" Received: from mail-bk0-f41.google.com ([209.85.214.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Sep 2013 17:19:19 +0200 Received: by mail-bk0-f41.google.com with SMTP id na10so1395770bkb.0 for ; Fri, 06 Sep 2013 08:19:18 -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; bh=kK+CqTlMrbsSisSEy9u5oEZPScdKV45YYJX9wer4P4w=; b=m2BI/uKMJwu6DccHX0AUd4D6ngCQ/KBHSWpiHzwU+LhW5yl7hyfAuMeNO8qfbiBYen Gb0UT71GWiC0KaAx4nNLPVVlBvnlAV9NoQ6hcNHy7S03K9rCFRZW0uDY9OV0PQXIl8qc 0EZacDxCAQCxVSy+t8defzi4dEEph4uQNFCF8ayiWzelIHJSzdPFJitYHXqUSsoNub4U s4Nu1IfAGm8pkvC1Q7KO6pCkLfzez5A1X5+lXwztoCBf0pIe+9xhgtZ6N4YEhpec3/bs FiCqsDTE/UdoaW4pcd/BVpCn+yBXsv7kEM5UMK/UYJIUwW3IP1g0NoYeNTNFtBOED2eP 95EA== X-Received: by 10.205.20.5 with SMTP id qm5mr316990bkb.46.1378480758661; Fri, 06 Sep 2013 08:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.236.193 with HTTP; Fri, 6 Sep 2013 08:18:38 -0700 (PDT) In-Reply-To: <5229DEF9.7040706@inria.fr> References: <5229DEF9.7040706@inria.fr> From: Gabriel Scherer Date: Fri, 6 Sep 2013 17:18:38 +0200 Message-ID: To: Romain Bardou Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Accelerating compilation Those are all good points, but they would be just as appropriate as feature requests in the OCaml bugtracker ( http://caml.inria.fr/mantis/ ). 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. 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