Comment author: @xavierleroy

You mean this Ninja? http://martine.github.io/ninja/

The problem -- and perhaps one of the strengths -- of ocamlbuild is that it discovers dependencies dynamically, while compiling. This is pretty much incompatible with any staging of the build process into 1- define dependencies, and 2- execute the build.

Comment author: @bobzhang

yes.
I was hacking LLVM these days, after tweaking ninja and ccache, the compilation process drops from 30 minutes to several minutes. For a large project, slow compilation is really productivity killer.

Compilation performance is important nowadays, one of the GoLang's key feature is its extremely fast building process, ocaml should be on par with go considering its design, unluckily the current two build system ocamlbuild, omake are both slow.

To my limited knowledge, if we have a robust ocamldep, and cut some features of ocamlbuild, this should be doable, like cmake for ninja.

Robust ocamldep is easy to get from syntactic level,
#open XX --- open a module from a persistent file
open XX -- non persistent open

What do you think?

Comment author: Camarade_Tux

It's probably easier to make ocamlbuild faster than have it create a ninja config (which would probably have to be regenerated very often).

Also, ccache is a tremendous performance boost for C. I'm fairly sure that without ccache, your build wouldn't be that much faster. And remember that LLVM is C++ with source files that take a very very very very long time to build and that it usually isn't the case for OCaml.

Comment author: @xavierleroy

The OCaml compilers (ocamlopt and especially ocamlc) are quite fast by today's standards, so this is very much an ocamlbuild problem: for example, you can get very fast compiles with a good old "make -j N", at the cost of writing a good Makefile.

Even with ocamlbuild's approach (dynamic discovery of dependencies), there are probably ways to make it faster and better exploit parallelism, but it looks like serious refactoring of ocamlbuild's code is needed. Contributions are welcome.

Improving ocamldep (possibly with changes in the language) was the topic of much internal discussion, esp. in connection with the "name spaces" discussion, but there is no clear plan of action.

I'm "suspending" this PR.