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 QAA27453; Fri, 16 Apr 2004 16:11:56 +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 QAA06291 for ; Fri, 16 Apr 2004 16:11:54 +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.12.10/8.12.10) with ESMTP id i3GECtjq030481 for ; Fri, 16 Apr 2004 16:12:57 +0200 Received: from [192.168.1.200] (ppp117-65.lns1.syd2.internode.on.net [150.101.117.65]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i3GEBhk2056314; Fri, 16 Apr 2004 23:41:44 +0930 (CST) Subject: Re: [Caml-list] Re: GODI vs. Ocamake From: skaller Reply-To: skaller@users.sourceforge.net To: Richard Cole Cc: skaller@users.sourceforge.net, caml-list , godi-list@ocaml-programming.de In-Reply-To: <407F3746.4000703@itee.uq.edu.au> References: <005e01c421f5$2dd45210$ef01a8c0@warp> <1081943666.20677.685.camel@pelican> <20040414164957.GA24089@tallman.kefka.frap.net> <1081991111.20677.877.camel@pelican> <20040415094716.GA7039@fichte.ai.univie.ac.at> <1082047130.20677.1218.camel@pelican> <407F3746.4000703@itee.uq.edu.au> Content-Type: text/plain Message-Id: <1082124702.20063.47.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 17 Apr 2004 00:11:43 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ocamake:01 sourceforge:01 2004:99 cole:99 interscript:01 interscript:01 python:01 dependencies:01 outputs:01 converge:01 fixpoint:01 bootstrap:01 pushes:01 python:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2004-04-16 at 11:30, Richard Cole wrote: > > > Please forgive my ignorance of interscript but I'm interested in what > problem interscript is trying to address. Package, build, test and document software systems using a unified source format. As a Literate Programming tool, you don't document your code .. you embed code in a document. Interscript is unique as follows. Most LP tools divide sources into 2 kinds: (a) documentation (b) source program codes. You use a tool to do two jobs: (a) extract the code (b) generate the documentation. Called 'tangling' and 'weaving'. Interscript sources can have a third kind of stuff in it. Arbitrary executable code written in a high level language (Python). I use executable code to generate programs, to generate documentation, to compile code, to run test suites, to do configuration management, and everything else. Some of these things have library and architecture support, for example a registry for test results which is part of the generated web site, other things do not: extensions may improve the product, but you can always embed them directly and install them as part of the build. > Another aspect of building systems is configuration management. This is > where my question really is. I've only worked on systems where > configurations differed via library dependencies. So for example the > linux version links to the linux-lowlevel library and the windows > version links to the window-lowlevel library. Is there some other aspect > of configuration management that interscript addresses? Not in particular: it doesn't really address anything. It simply allows you to embed configuration management code directly in the source tree in a uniform format. Well, there are some interesting ideas: for example you can 'include' a generated file before it is generated. No problem! That's because the idea is to run the build repeatedly until the outputs converge to a fixpoint: if something fails the first time it doesn't matter, just keep trying :D This is already clearly mandatory for LaTeX, and if you think about it is the only way to manage systems that bootstrap. > is much better to select tools that are supported on all the platforms > that you want to deploy your system. That pushes the "supporting > different build environments" problem onto someone else. Yeah, I chose Python. Shell script is too Unix centric, and it just doesn't compare with a real programming language: you don't need hacks kludges and glue to make it work. The downside is that being general purpose, a high level language like Python (or Ocaml) will need more code to get simple jobs done. That's the price for being able to write code for any job, no matter how complex, and knowing for SURE that you will not be defeated by restrictions of more specialised tools. Hey, you write code in Ocaml because it's not going to get in your way like C++ does .. and isn't building a system just another programming problem? -- 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