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 UAA03065; Sun, 5 Sep 2004 20:31:10 +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 UAA03110 for ; Sun, 5 Sep 2004 20:31:09 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i85IV6aB030758 for ; Sun, 5 Sep 2004 20:31:08 +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 i85IV0HY036049; Mon, 6 Sep 2004 04:01:01 +0930 (CST) Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 From: skaller Reply-To: skaller@users.sourceforge.net To: David Brown Cc: "Marcin 'Qrczak' Kowalczyk" , caml-list In-Reply-To: <20040905160936.GB29119@old.davidb.org> References: <4139ECD3.1050708@cs.caltech.edu> <001e01c492a6$872c7280$19b0e152@warp> <413A0921.7030607@ntlworld.com> <413A1E89.10806@libertysurf.fr> <1094361655.3352.476.camel@pelican.wigram> <87hdqc3kfr.fsf@qrnik.zagroda> <1094396893.3352.635.camel@pelican.wigram> <20040905160936.GB29119@old.davidb.org> Content-Type: text/plain Message-Id: <1094409059.3352.838.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Sep 2004 04:31:00 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 413B5B6A.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 2004:99 fixpoint:01 fixpoint:01 converge:01 converge:01 degenerate:01 interscript:01 degenerate:01 bug:01 fallback:01 bug:01 fallback:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2004-09-06 at 02:09, David Brown wrote: > On Mon, Sep 06, 2004 at 01:08:13AM +1000, skaller wrote: > > > Fixpoint iteration works and is universal. > > It isn't universal, though. There are pathalogical cases, even with common > tools where it never will stabilize. I think it is very rare to find a case which would stabilise with a manual order and not fixpoint iteration. Clearly, the claim to universality means 'the result will eventually converge to the same result as a correct hand crafted solution'. This claim isn't true. Every mathematician knows there are functions with local maxima which are not global maxima, and some algorithms which try to converge on the maxima will pick the wrong one. It is also possible to have processes which are so badly degenerate unless they're started with a sensible initial condition they just drop dead immediately and never recover. I know all about this one, since interscript is itself literate programmed and used to build itself -- and a few times I got a degenerate version with a hidden bug, installed it as the fallback, only to find the bug propagated .. and I had to manually edit the fallback Python script and LP sources (in parallel) to get the bootstrap converging. So yes, you're right, but in practice this is very rare, and its unlikely a conventional system would fare any better. . > There are also some old Ada compilers that wouldn't build without proper > ordering. Fortunately, with Ada, the order can be determined from the > source. I don't understand. If there is an partial order, fixpoint iteration should find it (eventually). It doesn't matter if a build fails, as long as at least one extra step succeeds each pass. > I'm not sure if having a specific build order is a bad thing, I just think > make's approach to determine it aren't right. Of course it isn't a bad thing! The point is to regard this kind of information as an optimisation. Fast builds are important. All real projects also contain test code, documentation, and all sorts of other stuff much of which is generated, and some of which is executed. And these relationships aren't flat either -- sometimes you need to generate a program to generate a program: in fact Autoconf is a perfect example of a long (and fragile) toolchain. The key thing is that the fixpoint just handles the lot automatically in almost all cases. [This isn't theory, I've been using it for well over a decade] In particular, you can certainly make the building of, for example, Ocaml codes fast by specifying an order -- possibly by executing some tool that generates it. [For the Felix project I just maintain a list by hand] However, to do that for every single tiny part of the system and get it right is probably quite hard, even harder to maintain, and at worst Goedel's theorem might intervene and make it completely impossible (since you'd have to manage the code managing the code ...) I guess the point I want to make here is that make systems just don't scale in practice, and that can't be fixed by extensions or new versions of it because the fault is fundamental to the concept of specified targets and dependencies. We need new concepts, and I'm proposing a new kind of solution: output tracking, convergence to fixpoints, an executable high power scripting system, a uniform packaging mechanism, and dependencies treated as optimisations. I'm not claiming interscript itself should be used: just that the ideas be considered as an alternative to the way make handles things. Interscript 1.0a11[123] Process Mon 06 Sep, 2004 04:22:36 (EST) SKIPPING (files skipped last run, which did not converge) BUILDNO 298 Unable to load sh tangler for "bagley/run.sh": using data $Id: flx_maker.ipk,v 1.75 2004/09/02 13:52:14 skaller Exp $ Pass 1 status: Files : 277 New : 0 Changed : 1 Unchanged: 276 You see it knows what has changed. And that one file probably has the CVS time stamp in it or something because this particular process never converges. But it doesn't matter -- my program still builds :) -- 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