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