All,

As you obviously know, OMake have not had a proper maintainer for a few
years now - while I did not completely abandon it, I did not have time
to devote to even little things (like pushing out a new 0.9.8.6 release
which I have been hoping to call "version 1.0", and which have been
lingering in "release candidate" mode for almost four years).

It is clear that there are quite a few people on this list with good
ideas on how to improve OMake (e.g. ability to write rules in OCaml
instead of/in addition to the OMake language seems like a good idea) -
so I am wondering - is there somebody who would be willing to take over
as the omake maintainer - ideally somebody whom people on this list
would trust with this role?

If there was some sort of consensus on this list about a new maintainer,
I would be happy to pass on this role (redirect omake.metaprl.org
accordingly, etc).

Aleksey

On 18.09.2014 13:14, 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