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 HAA04999; Sun, 5 Sep 2004 07:21:03 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA03907 for ; Sun, 5 Sep 2004 07:21:02 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i855L06B015944 for ; Sun, 5 Sep 2004 07:21:01 +0200 Received: from [192.168.1.200] (ppp210-32.lns2.syd3.internode.on.net [203.122.210.32]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i855KuHY072258 for ; Sun, 5 Sep 2004 14:50:58 +0930 (CST) Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list In-Reply-To: <413A1E89.10806@libertysurf.fr> References: <4139ECD3.1050708@cs.caltech.edu> <001e01c492a6$872c7280$19b0e152@warp> <413A0921.7030607@ntlworld.com> <413A1E89.10806@libertysurf.fr> Content-Type: text/plain; charset=UTF-8 Message-Id: <1094361655.3352.476.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 Sep 2004 15:20:56 +1000 Content-Transfer-Encoding: 8bit X-Miltered: at nez-perce with ID 413AA23C.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 sourceforge:01 2004:99 matthieu:01 dubuget:01 cannasse:01 yam:99 yam:99 damien:01 ens-lyon:01 damien:01 outputs:01 outputs:01 dependencies:01 interscript:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-09-05 at 05:59, Matthieu Dubuget wrote: > chris.danx a écrit : > > Nicolas Cannasse wrote: > > >> However, I can't help thinking that I don't write to learn yet another > >> language for writing my Makefiles... Why not using directly OCaml for > >> writing Makefiles and exposing all nice OMake features through a > >> library ? > May be YaM is a first step toward this. YaM was written by Damien Pous: > > http://perso.ens-lyon.fr/damien.pous/shared/ocaml/YaM/ My personal take is: all 'make' based build systems are fundamentally flawed because they're based on the wrong concept. The basic problem is that make assumes a fixed set of target outputs and has rules like: A depends on B: use P to make A from B This means you have to know all the outputs, dependencies, and build rules in advance which is *never* the case on any realistic system. The way forward is to rethink the fundamentals. Interscript works like this: if anything changes rebuild This rule is universal. Rebuild rules are arbitrary executable code, the process is terminated by detecting a fixpoint, which it can do by tracking all outputs. The logic here is reversed. You execute a 'rule' because it is part of an unfixed build (a process that hasn't converged to a fixpoint) NOT because you need to satifsy a dependency. The problems are ones of optimisation, not working around the fact 'make' is both incomplete and unsound. In other words, we can use mathematics to reason about how to optimise it, rather than trying to 'improve' something which is fundamentally broken. [Adding optimisations to a universal solution is fundamentally different to extending an incomplete one] For Omake -- the 'automatic file system monitoring' is not merely a 'convenience' to save typing 'omake'. Rather it should be viewed as *fundamental* change to the usual build paradigm -- its a step in the right direction. It should solve the following equation: d.dvi,d.aux = latex d.tex,d.aux,d.dvi which is necessary to use latex. (The aux file holds location of labels which are needed to generate forward references whose size may change with the location which may change the locations of labels ..) In interscript, I use dynamic code generation. This is very clumbsy -- print out a Python file then use 'execfile' to execute it. Some kind of more advanced partial evaluator is probably the way to go. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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