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 SAA05371; Fri, 21 Nov 2003 18:13:55 +0100 (MET) 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 SAA05195 for ; Fri, 21 Nov 2003 18:13:54 +0100 (MET) Received: from mail3.tpgi.com.au (mail.tpgi.com.au [203.12.160.59]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hALHDp128942 for ; Fri, 21 Nov 2003 18:13:52 +0100 (MET) Received: from 203-213-81-92-syd-ts13-2600.tpgi.com.au (203-213-81-92-syd-ts13-2600.tpgi.com.au [203.213.81.92]) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id hALHDDj26372; Sat, 22 Nov 2003 04:13:15 +1100 Subject: Re: [Caml-list] Building large and portable projects From: skaller Reply-To: skaller@ozemail.com.au To: sylvain.le-gall@polytechnique.org Cc: Nicolas Cannasse , David Brown , Martin Jambon , caml-list@inria.fr In-Reply-To: <20031121064950.GA836@gallu.homelinux.org> References: <20031120195614.GB441@gallu.homelinux.org> <000f01c3afd1$30033c90$0274a8c0@PWARP> <20031121052549.GA8599@davidb.org> <008301c3aff3$1030e760$0274a8c0@PWARP> <20031121064950.GA836@gallu.homelinux.org> Content-Type: text/plain Message-Id: <1069431167.5426.45.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 Nov 2003 03:12:48 +1100 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 le-gall:01 0900,:01 cannasse:01 interscript:01 conceptually:01 autoconf:01 recognizes:01 interscript:01 ocamldoc:01 fixpoints:01 fixpoints:01 dependencies:01 outputs:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2003-11-21 at 17:49, sylvain.le-gall@polytechnique.org wrote: > On Fri, Nov 21, 2003 at 02:48:17PM +0900, Nicolas Cannasse wrote: > On the other hand the aim will be to have a self contained tools ( ie > when you write a makefile you use rm, cp, touch > .. here the aims will be > to have it in ocaml ). So you could build on every platform which > support ocaml. The goal is impossible. For example, all my Ocaml source is literate programmed. You surely aren't going to rewrite Interscript in Ocaml are you? At best, you can cheat with system() function but then all the dependency checking is lost. Make systems are all conceptually wrong. There a huge number of projects to replace Make (and autoconf et al) and not a single one I've seen recognizes that the fundamental design is flawed .. instead they all try to copy the make idea. First observe that building a system is a process where it is not always possible to determine the full sequence of commands in advance. Sometimes, you have to perform some action before you can decide what to do next. Example: you cannot build interscript packaged sources or a tarball directly, you have to extract the contents first. Example: the rules for building a package may have to be generated or extracted from the package. Next observe that the linear dependency checking is naive. First, what some target depends on can be conditional: obviously true for C :-) But it is much worse. A target can depend on itself. Interscript assumes that. An example is a Latex build, which depends on auxilliary files generated by the build [Ocamldoc output can take 4 passes to fixate for example]. This leads to the first novel idea. Fixpoints. Interscript is based on that idea. With fixpoints, you dont CARE about dependencies. What you do is repeatedly execute some process until the defined outputs are stable. The inputs do not need to be known. Now we backstep. We try to *predict* whether the outputs will be the same this run as last. If we can -- and we have to be *sure* -- we can terminate one cycle earlier. This is dependency checking with a new twist: its optional. :-) Well, I will jump ahead now. A build system does NOT have targets. That's a bad idea too. A build systems has processes and files. Lets call the processes ARROWS and the files OBJECTS. Oh. That's a category. We allow of course, products of files (multiple outputs and inputs) and sums of files (choose one of several). [And of course we'd better make it cartesian closed and allow processes to be files .. called scripts .. :] The control system allows you to 'click' on an arrow to execute the process. This is manual running. It also allows to to click on a object to run all the processes required to produce the object. By using a caching concept, some process can be elided as an optimisation. For example .c -cc--> .o -link--> exe, we can use the cached .o instead of running cc on the .c provided the .c is older. BTW: I have *built* this system, including a graphic interface which allowed construction of the build category. I needed this much power. Make is a total joke. What I was doing was writing a book, literate programmed of course, and needed to generate a LOT of different documents -- I had to build code, test it, capture the output, typeset the book, build indices, contents ... In a *real* build system, you do NOT want to make everything from scratch everytime. Sometime you're happy using old data, at least for a while. Anyhow .. a lot of new ideas for a build system are here. Just copying the make concept is not going to solve any problems .. its going to make things much WORSE by having yet another inadequate tool -- which of course the poor client will have to build, making the tool chain even longer. [Trying to replace Make destroyed Boost IMHO] ------------------- 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