Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Aleksey Nogin <nogin@cs.caltech.edu>]

On 04.09.2004 10:42, Nicolas Cannasse wrote:

> Other way to ask the question : what features make the OMake language better
> than OCaml for writing Makefiles ? Or is it just syntactic sugar ?

It's not about language, it's about the features that the build system 
provides. Here is a list of features of omake that I think would be hard 
or impossible to reproduce in a "Makefile generator":

- Omake knows that a single build command can produce more that one 
file! (Think omcamlopt producing both .cmx and .o, or ocamlc on an 
.mli-free .ml producing both .cmo and .cmi). This really simplifies life 
as you do not have to hack around your build system not knowing the 
side-effects of commands you invoke. See also the "Quick example" below.

- Persistent filesystem monitoring (based on FAM) mode - in this mode, 
as soon as one of the source files is changed, the build is process is 
restarted accordingly (whether omake was idle or already building 
something in the project). In my experience this significantly speeds up 
the process of fixing typos, type checking errors, etc.

- As already mentioned by Yaron, the commands for building a file are 
themselves included in the dependency for the file.

- Complete timestamp/MD5sum testing for file modifications. Note that 
once you make the dependency information truly complete (which is the 
goal of omake), then this becomes a must. Often not all changes in a 
dependencies result in the generated file being actually changed. When a 
file stays the same after it is rebuilt, you want to detect this to 
avoid rebuilding too much.

- Being able to specify "dependencies of dependencies". In other words, 
not only you can specify how to scan a file for dependencies (e.g. 
ocamldep, "gcc -MM", etc), but you can also specify what the scanning 
process itself depends on. For example, if you have a custom 
ocamldep-like program, then you can specify that it needs to be built 
before scanning dependencies of certain files and that whenever that 
binary changes, the dependencies of those files need to be recomputed.

- A global view of the whole project (not just per-directory). This not 
only helps in making sure that the dependency graph is as complete as 
possible, but also gives the parallelizer (omake supports the same -j 
option as make) more freedom. Of course, in a "Makefile generator" you 
could try to generate one huge Makefile for a project, but even with 
such a file if you ever end up calling make recursively, it will no 
longer have a complete view of the whole project.

- Quick example: suppose that you have a file "foo.ml" (with no foo.mli) 
and a file "bar.ml" that refers to "Foo" and supposed that you are 
compiling bytecode. The standard ocamldep would generate

foo.cmo: bar.cmo

dependency. Which means that whenever bar.ml changes, foo.cmo (and 
everything that depends on it) will get rebuilt.

In omake's case, our version of ocamldep will generate the "proper"

foo.cmo: bar.cmi

Then, omake's rule for building .cmi specifies that in the absence of an 
.mli file (and when no rule for building such an .mli is present), use 
"ocamlc %.ml" for building the .cmi. Next, omake will check whether .cmi 
have changed (compared to what it was the last time omake compiled it, 
not compared to what it was right before!) and if not (imagine that 
you've change the code in .ml without affecting the signature - bar.cmo 
would change, but bar.cmi would not), then foo.cmo will not get rebuilt.

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners