|Anonymous | Login | Signup for a new account||2015-03-31 18:52 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006100||OCaml||OCamlbuild (the tool)||public||2013-07-29 02:12||2013-08-01 10:40|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0006100: generate a backend for ninja?|
|Description||One of the main drawback for ocamlbuild is that it's very slow. |
Is it possible to make ocamlbuild a meta build system to generate ninja file?
|Tags||No tags attached.|
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.
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?
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.
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.
|2013-07-29 02:12||hongboz||New Issue|
|2013-07-29 16:38||xleroy||Note Added: 0009987|
|2013-07-29 16:38||xleroy||Status||new => feedback|
|2013-07-30 03:51||hongboz||Note Added: 0010006|
|2013-07-30 03:51||hongboz||Status||feedback => new|
|2013-07-30 20:17||Camarade_Tux||Note Added: 0010013|
|2013-08-01 10:40||xleroy||Note Added: 0010053|
|2013-08-01 10:40||xleroy||Status||new => resolved|
|2013-08-01 10:40||xleroy||Resolution||open => suspended|
|Copyright © 2000 - 2011 MantisBT Group|