Ocaml could be executed as shell code. Why create another langage and not use an ocaml program (+ library) to build an other ocaml program ? The first program could be interpreted as shell code. 2014-09-19 14:23 GMT+02:00 Alain Frisch : > 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 >> > > > -- > 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 >