Re: [Caml-list] improve omake [was One build system to rule them all]

[Alain Frisch <alain@frisch.fr>]

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