caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Aleksey Nogin <nogin@metaprl.org>
To: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] improve omake [was One build system to rule them all]
Date: Thu, 18 Sep 2014 13:30:03 -0700	[thread overview]
Message-ID: <541B40CB.4050102@metaprl.org> (raw)
In-Reply-To: <CANcqPu7vkkDKM8kU9hSen6xZACsvOQ3EPaPBXRQmF4XBvPT+Vw@mail.gmail.com>

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


  reply	other threads:[~2014-09-18 20:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 20:14 Bob Zhang
2014-09-18 20:30 ` Aleksey Nogin [this message]
2014-09-20 14:59   ` Jun Furuse
2014-09-18 20:34 ` Sébastien Dailly
2014-09-18 21:32 ` Yaron Minsky
2014-09-19 12:23 ` Alain Frisch
2014-09-19 12:29   ` Nicolas Boulay
2014-09-19 13:36   ` Gerd Stolpmann
2014-09-19 14:00     ` Alain Frisch
2014-09-19 15:18       ` Yaron Minsky
2014-09-19 17:18         ` Gerd Stolpmann
2014-09-19 17:48           ` Yaron Minsky
2014-09-23 10:40         ` Alain Frisch
2014-09-23 10:58           ` Mark Shinwell
2014-09-23 20:12             ` Alain Frisch
2014-09-24  2:35               ` Yaron Minsky
2014-09-22 15:33 Bob Zhang
2014-09-24 13:37 ` Gerd Stolpmann
2014-09-24 15:47   ` Alain Frisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=541B40CB.4050102@metaprl.org \
    --to=nogin@metaprl.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).