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 00F857FACD for ; Fri, 19 Sep 2014 15:36:15 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.24; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.24; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.17.24; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsBACAwHFTU4xEYnGdsb2JhbABaBoNgV4MBxmoKh00BgQMWAREBAQEBAQYNCQkUKoQDAQEBAwEjMhsJBQsLGCoCAlcGEwmILQwJrGgUIW8NlQoBF4l+HIUEIB0hBQeCN0ESgUEFhQ0CgRGELodBg32IaIVmBZFjagGCSQEBAQ X-IPAS-Result: AtsBACAwHFTU4xEYnGdsb2JhbABaBoNgV4MBxmoKh00BgQMWAREBAQEBAQYNCQkUKoQDAQEBAwEjMhsJBQsLGCoCAlcGEwmILQwJrGgUIW8NlQoBF4l+HIUEIB0hBQeCN0ESgUEFhQ0CgRGELodBg32IaIVmBZFjagGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.04,555,1406584800"; d="asc'?scan'208";a="96648982" Received: from mout.kundenserver.de ([212.227.17.24]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Sep 2014 15:36:10 +0200 Received: from office1.lan.sumadev.de (dslb-178-004-068-137.178.004.pools.vodafone-ip.de [178.4.68.137]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MIe3k-1XSmUi3QiG-002D6U; Fri, 19 Sep 2014 15:36:09 +0200 Received: from [192.168.10.103] (ip-37-201-182-45.hsi13.unitymediagroup.de [37.201.182.45]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 1E1F9DC270; Fri, 19 Sep 2014 15:36:08 +0200 (CEST) Message-ID: <1411133763.2930.28.camel@zotac> From: Gerd Stolpmann To: Alain Frisch Cc: Bob Zhang , Caml List Date: Fri, 19 Sep 2014 15:36:03 +0200 In-Reply-To: <541C2037.5030303@frisch.fr> References: <541C2037.5030303@frisch.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ad+4LTavJirud59FrK6A" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 X-Provags-ID: V02:K0:1kf3UfNs9lUPBIEmPDqh1isFxjKdz0w37rJbhAZRH2f Rww9ELDRPfbMdKnL7ya0e8tZFmBJyqnz+RB9koQ3HBJ+9jE2gl AA3KxAu1gACNDS9/KH6fen9418y6CQIaJpL2wRtMVZgA6FY6EP batWqjE868Ew2+JWwXMGNFNN4hwkSsfE7wq/e4SLakoGa3cFSN ipn33CKe05RnpER9qkMIjxC8/lY6fG0Lua0Nmgu/WBiN6poZz+ KAb9XS8MbH+4tF1Ru9ZGaAbNuNgWm15RANdB6/45+pppwh/lnU WNtAuhC72hYbvXpZS3zRAXPD6ZoZxIA3L8qXEZtuXx1IVWuUXS aiMnDs0K1YMfSHy21rGTSVvkXqgm0KAOHn0e4Orvi X-UI-Out-Filterresults: notjunk:1; Subject: Re: [Caml-list] improve omake [was One build system to rule them all] --=-ad+4LTavJirud59FrK6A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Freitag, den 19.09.2014, 14:23 +0200 schrieb Alain Frisch: > I'm not sure of the benefit of using OCaml to write custom rules (but=20 > why not).=20 Well, I run frequently into the difficulty that I need some special omake function that would be trivial to develop in OCaml (e.g. associating some data with some other data, filtering things, doing string transformations), but for writing it in the omake language I need some time for developing and testing. I have a quite simple idea to improve this: Besides OMakefile there could also be an OMakefile.ml, and you can define any helper functions there, and they would be automatically callable from the OMakefile. I think this is not really complicated to do - you'd need to build a custom omake executable whenever OMakefile.ml changes, and need to scan the OMakefile.ml interface for function signatures that match the form that is callable, and you need to generate some glue code. (Later this idea could be extended by allowing OCaml code to emit new rules, as described in an earlier post.) > The omake language could certainly be improved, both from a=20 > syntactic and from a semantic point of view. (I think there was some=20 > project, in the latest development version, to introduce a syntax closer= =20 > to programming languages, with un-prefixed variables and delimited=20 > string literals.) omake picks up ideas from shell programming, and this is a different thinking than in programming languages. For example, if you define files =3D x1 x2 x3 the variable is not set to a string, but to a sequence of words, so when you later call ls $(files) the command is started with three arguments, and not one. If you define files =3D "x1 x2" x3 this is a sequence with two words only (i.e. there are string delimiters, only the outermost delimiters are normally omitted). Using a special datatype for word sequences is a very nice idea, as it eliminates the need for quoting (as in the shell). However, it is a somewhat unusual thinking for most OCaml programmers, especially because these sequences can get recursive (i.e. it's not a string list, but a string tree, a bit like s-expressions in Lisp). > Personally, I don't care too much about the syntax.=20 > The most important problem I can see with the language is the=20 > difficulty to "pass" information from one part of the project to another= =20 > one. The only two ways I'm aware of to achieve that are: (i) rely on=20 > the scoping rules, which in practice means a one-directional flow of=20 > data (typically from a toplevel OMakefile to OMakefile in=20 > sub-directories) or (ii) piggy-back the more "imperative" dependency=20 > graph (attaching dependencies to dummy "tag" files can be used to=20 > implement Boolean markers than can be put on a target in one place and=20 > observed from another place). A typical situation where information=20 > should flow from one part to another: each library (in its own=20 > directory) exports some variables (such as some link flags), to be used=20 > by client parts. I see what you mean. In a recent project I had to define all variables with library names, findlib names, intra-project library dependencies etc. in the global OMakefile, because they are needed in potentially all sub-OMakefiles. That's of course not where these things are best naturally defined. Maybe we should allow to switch to global context anywhere? I think this is solvable. > Several people complained about the startup performance of omake on big=20 > projects. It would be very useful to know whether this comes from the=20 > processing of the omake "scripts" (in which case some energy might be=20 > put into improving the interpreter and the internal data structures -- I= =20 > don't see a deep reason for spending several seconds on interpreting=20 > even quite large scripts) or from scanning the file system for file=20 > changes (in which case nothing much could be done about it). Could be something simple, like matching the wildcard rules against the real files. Another wish I have: There could be a mode that explains why a certain file is NOT rebuilt. More than once I forgot to create a manual dependency for something, and some file was not rebuilt that should have. It would be cool if I could get help from omake: omake -why-not file would list all potential build rules and why they aren't activated. Gerd >=20 > Alain >=20 >=20 >=20 > 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 >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-ad+4LTavJirud59FrK6A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJUHDFDAAoJEAaM4b9ZLB5T9JgIAI+EJwEm/ITToXnf3N4JKYAI 9A71aeYeitR04za6UVDgXGw6bvfwJ0I+Ydj1Za9/W1iK51BHx5cE5ihyk7rorO/2 14/2XPvgE5C2dNlnoQ9yfZ3wyI1Jxz4XocfWYCcW3YP1sNRSl9OLC0SsG/YHTbh/ S04QoQUgiYsQ/STT6z+UQ/IEIQ658DjFs2z8upAcSirGUenHc8H4YIMMEelx8V0Z xPVaH+Nkul/dLMVWI4xfCDGiASqxqEFhqd8kg/TJbz5aN8NOBAWjRusNANBAyc2K LM0AcOVlfq6Zz4BfQS+HY4C6jSWykqZ7CWvoDqYnXbmM9ic4bbq9DhvUpuPcKtU= =qeOl -----END PGP SIGNATURE----- --=-ad+4LTavJirud59FrK6A--