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

[Yaron Minsky <yminsky@janestreet.com>]

This is not the main point of your post, but to reply to your concerns
on Jenga:

- I'm not sure why the dependency chain of Jenga matters much.  You
  need camlp4 to build it, but not to use it.  In any case, I expect
  that in a few months, that dependency will be gone as we migrate to
  extension points.

- The examples are big, but that's mostly because it takes a lot of
  code to precisely express OCaml's dependency and build rules.  Other
  tools either hide that code from you (ocamlbuild) or have incomplete
  rules that don't quite do the right thing (omake).

Note that with our Jenga rules, we do have simple build specification
files.  Here's the one for async_kernel, which emphasizes how simple
these can be.

    (library
     ((name async_kernel)
      (libraries (core))))

Here's the one for async_unix, which is a little more complicated.

    (library
     ((name async_unix)
      (libraries (async_kernel
                  core))
      (c_names (dump_core_on_job_delay_stubs))
      (preprocess (((pps (JANE pa_macro)) All)))))


And here's a much more complicated one, for core:

    (rule
     ((targets (config.mlh config.h))
      (deps (discover.sh))
      (action "${<} ${OCAML} ${OCAMLC} config.mlh config.h -DLINUX_EXT
-DPOSIX_TIMERS -DWORDEXP")))

    (rule
     ((targets (version_defaults.mlh))
      (deps ())
      (action "echo 'DEFINE DEFAULT_VERSION   = Version_util.version'
   > version_defaults.mlh
               echo 'DEFINE DEFAULT_BUILDINFO =
Version_util.build_info' >> version_defaults.mlh
               echo 'DEFINE BUILD_VERSION_UTIL'
  >> version_defaults.mlh")))

    (library
     ((name core)
      (libraries
       (core_kernel
        sexplib_unix
        version_util_fallback))
      (interfaces (core_kernel))
      (extra_cflags (-D_LARGEFILE64_SOURCE))
      ;; We omit [-pedantic] because
      ;; [bigstring_recvmmsg_assume_fd_is_nonblocking_stub] in
      ;; bigstring_stubs.c uses variable-length arrays rather than [alloca].
      (avoid_cflags (-pedantic))
      (library_flags (-cclib -lrt))
      (c_names
       (backtrace_stubs
        bigstring_stubs
        crc_stubs
        iobuf_stubs
        linux_ext_stubs
        ocaml_utils_stubs
        recvmmsg
        signal_stubs
        syslog_stubs
        time_stamp_counter_stubs
        time_stubs
        timespec
        unix_stubs))
      (preprocess (((pps (JANE pa_macro)) All)))
      (preprocessor_deps (version_defaults.mlh config.mlh))))

The point is, there is a simple DSL embedded that we use for
specifying individual projects, but it's _very_ simple, with more
complicated things done by extending the build rules, in OCaml.
Really, I think this is the right design.  Build DSLs are typically
horrible programming languages, and you don't want to do anything
complicated with them.

That said, it's not ready for prime time yet, mostly in that it needs
some portability work, and some work to get good default rules that
people can use externally from Jane Street, with a good story for
interacting with ocamlfind and the like.

But we'd love to have people trying it out and helping us work out
those use cases.  Indeed, we've already exported a version of our
build rules that are suitable for building with OCaml 4.02:

    https://github.com/janestreet/jenga/tree/master/examples/js-build-style

y

On Thu, Sep 18, 2014 at 4:14 PM, Bob Zhang <bobzhang1988@gmail.com> 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