From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 BDC7E7FACE for ; Fri, 19 Sep 2014 14:23:20 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0BAL0fHFTB/BfUnGdsb2JhbABgg2CDWMZph00BgRgBEQEBAQEBBg0JCRQqhAQBAQQjFTgIARALGAICBRYLAgIJAwIBAgE3AQ0GAQwBBwEBiD4JrEOWPAETBIEsiG6FBF4FB4J4gVMBBIUNAoU/iz6HB4dMkWODNAEBAQ X-IPAS-Result: Aq0BAL0fHFTB/BfUnGdsb2JhbABgg2CDWMZph00BgRgBEQEBAQEBBg0JCRQqhAQBAQQjFTgIARALGAICBRYLAgIJAwIBAgE3AQ0GAQwBBwEBiD4JrEOWPAETBIEsiG6FBF4FB4J4gVMBBIUNAoU/iz6HB4dMkWODNAEBAQ X-IronPort-AV: E=Sophos;i="5.04,554,1406584800"; d="scan'208";a="96631890" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Sep 2014 14:23:20 +0200 Received: from [192.168.1.132] ([92.151.92.168]) by mwinf5d61 with ME id t0PJ1o00L3dx2K8030PJEe; Fri, 19 Sep 2014 14:23:19 +0200 X-ME-Helo: [192.168.1.132] X-ME-Auth: bGV4aWZpQHdhbmFkb28uZnI= X-ME-Date: Fri, 19 Sep 2014 14:23:19 +0200 X-ME-IP: 92.151.92.168 Message-ID: <541C2037.5030303@frisch.fr> Date: Fri, 19 Sep 2014 14:23:19 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Bob Zhang , caml-list-request@inria.fr CC: Caml List References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] improve omake [was One build system to rule them all] Hi Hongbo, It's great to hear that you'll put some energy into omake. Despite some of its shortcomings, it's a great and mature tool, which is nice for both simple projects and large ones. It certainly deserves some good treatment :-) and it's actually the only build system developed around OCaml which put so much emphasis, right from the beginning, on good Windows support. I'm not sure of the benefit of using OCaml to write custom rules (but why not). The omake language could certainly be improved, both from a syntactic and from a semantic point of view. (I think there was some project, in the latest development version, to introduce a syntax closer to programming languages, with un-prefixed variables and delimited string literals.) Personally, I don't care too much about the syntax. The most important problem I can see with the language is the difficulty to "pass" information from one part of the project to another one. The only two ways I'm aware of to achieve that are: (i) rely on the scoping rules, which in practice means a one-directional flow of data (typically from a toplevel OMakefile to OMakefile in sub-directories) or (ii) piggy-back the more "imperative" dependency graph (attaching dependencies to dummy "tag" files can be used to implement Boolean markers than can be put on a target in one place and observed from another place). A typical situation where information should flow from one part to another: each library (in its own directory) exports some variables (such as some link flags), to be used by client parts. Several people complained about the startup performance of omake on big projects. It would be very useful to know whether this comes from the processing of the omake "scripts" (in which case some energy might be put into improving the interpreter and the internal data structures -- I don't see a deep reason for spending several seconds on interpreting even quite large scripts) or from scanning the file system for file changes (in which case nothing much could be done about it). Alain On 09/18/2014 10:14 PM, Bob Zhang wrote: > Dear camlers, > I have done some work to improve omake available here: > https://github.com/bobzhang/omake-fork/tree/work > Before deciding spending some time in improving omake, I have tried > various build systems. > 1. ocamlbuild > ocamlbuild is really nice for small to medium projects and I have > used it pervasively in my personal projects and corporation projects. It > works pretty well in most cases. > There are mainly three drawbacks: > a. Easy things hard to do. > Even for some very trivial things, if you don't write > myocamlbuild.m for a long time, you have to google ocamlbuild API and > figure it out how to do it correctly. > b. Error messages hard to understand > It's cool that ocamlbuild detect dependencies dynamically, > when it does not work out, in general, I would turn on -verbose and > search which part goes wrong. > c. no parallellism > This is fatal and main reason that I gave it up > 2. ocp-build > I tried it for my hobby project, it's not close to maturity yet. > 3. jenga > Jenga looks promising, but I don't think it would be usable > inside our company, the dependency is huge, more importantly, its > dependency chain includes Camlp4 which we can not rely on. Also, looking > at the examples, it is quite verbose even for trivial projects. > > omake has its own drawbacks as well, for example, the language is > overly complex and error message is hard to understand(still better than > ocamlbuild), startup speed is slow, no easy FFI interface to write rules > in OCaml language itself, but that's all we can find a way to fix. > > -- > Regards > -- Hongbo Zhang