> * A wiki is not documentation. The reference document that documents the
>   conceptual model of ocamlbuild, the available tags and their effects
>   and a clear/understandable documentation of the *API* are still
>   missing. How does ocamlbuild build your project, how does it compute
>   dependencies, how does it track changes, etc.

I agree we have to think, how to build up to date documentation as our
top priority. Embarrassingly it's been on my plate for quite long. Now I
think time is up, to update it.

> * Given our struggles with myocamlbuild.ml I wonder whether the current
>   API is the right one or if it's just a matter of the missing
>   documentation. And this is from a person who has written significant
>   myocamlbuild.ml plugins [1,2]. If that is a sign of something my
>   current strategy is to switch to a mixture of shell scripts and
>   ocamlbuild invocations to side-step myocamlbuild.ml whenever possible.

> * Easy built-in support for C stubs/libraries is missing. E.g. I'd be
>   glad if I hadn't to write a myocamlbuild.ml file for a simple project
>   like this [3].

The trouble is that OCamlbuild itself is really a build framework. It
contains a lot of rules out of the box, though, but they usually all
related to ocaml system, and not the external tools. Because we have no
method of distributing various plugins for OCamlbuild (Coq rules,
Js_of_ocaml rules, C rules, LaTeX rules etc.) it means that every
project hacks it own plugin, perhaps by copy pasting from the wiki. This is
un-satisfactory and a real root of the problem. Fortunately the solution
for this exist, we should allow ocamlfind packages to install needed
rules. We could say then:

ocamlbuild -use_package js_of_ocaml.ocamlbuild

Wojciech



On Fri, Jul 26, 2013 at 11:48 AM, Daniel Bünzli <daniel.buenzli@erratique.ch
> wrote:

> Le vendredi, 26 juillet 2013 à 08:25, Wojciech Meyer a écrit :
> > I believe ocamlbuild HAS clear and sound design, more than other
> > tools. In fact many ideas in ocamlbuild are novel, and interesting, this
> > is the major reason I maintain it, otherwise I'd not be interested in
> > doing so.
>
>
> I completely agree. When it came out I jumped on the project --- was
> burned out by a recursive make file trying to compile only things that
> changed across developing libraries used by another developing project;
> using just ocamlbuild, a _tags file and symlinks solved it all in a minute.
>
> However:
>
> * A wiki is not documentation. The reference document that documents the
> conceptual model of ocamlbuild, the available tags and their effects and a
> clear/understandable documentation of the *API* are still missing. How does
> ocamlbuild build your project, how does it compute dependencies, how does
> it track changes, etc.
>
> * Given our struggles with myocamlbuild.ml I wonder whether the current
> API is the right one or if it's just a matter of the missing documentation.
> And this is from a person who has written significant myocamlbuild.mlplugins [1,2]. If that is a sign of something my current strategy is to
> switch to a mixture of shell scripts and ocamlbuild invocations to
> side-step myocamlbuild.ml whenever possible.
>
> * Easy built-in support for C stubs/libraries is missing. E.g. I'd be glad
> if I hadn't to write a myocamlbuild.ml file for a simple project like
> this [3].
>
> Best,
>
> Daniel
>
> [1] http://brion.inria.fr/gallium/index.php/Compiling_C_with_gcc
> [2] http://darcs.ocamlcore.org/ocamlunix/myocamlbuild.ml
> [3] https://github.com/dbuenzli/rpng
>
>