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

[Nicolas Boulay <nicolas@boulay.name>]

[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]

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 <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
>>
>
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 5568 bytes --]