From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA08437; Sun, 5 Sep 2004 22:38:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA05887 for ; Sun, 5 Sep 2004 22:38:26 +0200 (MET DST) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i85KcPpC009868 for ; Sun, 5 Sep 2004 22:38:25 +0200 Received: from [192.168.1.100] (charter-242-009.caltech.edu [131.215.242.9]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 7DBBDDF2B4; Sun, 5 Sep 2004 13:38:24 -0700 (PDT) Message-ID: <413B7944.5010807@cs.caltech.edu> Date: Sun, 05 Sep 2004 13:38:28 -0700 From: Aleksey Nogin Organization: California Institute of Technology, Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040901 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Nicolas Cannasse , Caml List Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 References: <4139ECD3.1050708@cs.caltech.edu> <001e01c492a6$872c7280$19b0e152@warp> In-Reply-To: <001e01c492a6$872c7280$19b0e152@warp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 413B7941.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 cannasse:01 cmx:01 ocamlc:01 fam:99 restarted:01 yaron:01 dependencies:01 dependencies:01 ocamldep:01 gcc:01 -mm:01 recursively:01 foo:01 foo:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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