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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

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

Am Freitag, den 19.09.2014, 14:23 +0200 schrieb Alain Frisch:
> I'm not sure of the benefit of using OCaml to write custom rules (but 
> why not). 

Well, I run frequently into the difficulty that I need some special
omake function that would be trivial to develop in OCaml (e.g.
associating some data with some other data, filtering things, doing
string transformations), but for writing it in the omake language I need
some time for developing and testing. I have a quite simple idea to
improve this: Besides OMakefile there could also be an OMakefile.ml, and
you can define any helper functions there, and they would be
automatically callable from the OMakefile. I think this is not really
complicated to do - you'd need to build a custom omake executable
whenever OMakefile.ml changes, and need to scan the OMakefile.ml
interface for function signatures that match the form that is callable,
and you need to generate some glue code. (Later this idea could be
extended by allowing OCaml code to emit new rules, as described in an
earlier post.)

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

omake picks up ideas from shell programming, and this is a different
thinking than in programming languages. For example, if you define

files = x1 x2 x3

the variable is not set to a string, but to a sequence of words, so when
you later call

ls $(files)

the command is started with three arguments, and not one. If you define

files = "x1 x2" x3

this is a sequence with two words only (i.e. there are string
delimiters, only the outermost delimiters are normally omitted). Using a
special datatype for word sequences is a very nice idea, as it
eliminates the need for quoting (as in the shell). However, it is a
somewhat unusual thinking for most OCaml programmers, especially because
these sequences can get recursive (i.e. it's not a string list, but a
string tree, a bit like s-expressions in Lisp).

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

I see what you mean. In a recent project I had to define all variables
with library names, findlib names, intra-project library dependencies
etc. in the global OMakefile, because they are needed in potentially all
sub-OMakefiles. That's of course not where these things are best
naturally defined.

Maybe we should allow to switch to global context anywhere? I think this
is solvable.

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

Could be something simple, like matching the wildcard rules against the
real files.

Another wish I have: There could be a mode that explains why a certain
file is NOT rebuilt. More than once I forgot to create a manual
dependency for something, and some file was not rebuilt that should
have. It would be cool if I could get help from omake:

omake -why-not file

would list all potential build rules and why they aren't activated.

Gerd

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

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]