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 DAA18837; Fri, 16 Apr 2004 03:31:06 +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 DAA18843 for ; Fri, 16 Apr 2004 03:31:05 +0200 (MET DST) Received: from gum.itee.uq.edu.au (gum.itee.uq.edu.au [130.102.66.1]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3G1W5jq031975 for ; Fri, 16 Apr 2004 03:32:06 +0200 Received: from nut.itee.uq.edu.au (nut.itee.uq.edu.au [130.102.66.13]) by gum.itee.uq.edu.au (8.12.10/8.12.10) with ESMTP id i3G1UkGR001368; Fri, 16 Apr 2004 11:30:47 +1000 (EST) Received: from itee.uq.edu.au (g613-8948.itee.uq.edu.au [130.102.66.112]) by nut.itee.uq.edu.au (8.12.10/8.12.9) with ESMTP id i3G1UkA6019949; Fri, 16 Apr 2004 11:30:46 +1000 (EST) Message-ID: <407F3746.4000703@itee.uq.edu.au> Date: Fri, 16 Apr 2004 11:30:46 +1000 From: Richard Cole User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: skaller@users.sourceforge.net CC: caml-list , godi-list@ocaml-programming.de Subject: Re: [Caml-list] Re: GODI vs. Ocamake 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> In-Reply-To: <1082047130.20677.1218.camel@pelican> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checked: This message probably not SPAM X-Spam-Score: -2.1 X-Spam-Tests: EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG X-Spam-Report: -2.10 points, 8 required; * -0.5 -- Has a valid-looking References header * -0.5 -- Has a In-Reply-To header * 0.0 -- User-Agent header indicates a non-spam MUA (Mozilla) * -0.1 -- Has a X-Accept-Language header * -0.5 -- BODY: Contains what looks like an email attribution * -0.5 -- Reply with quoted text X-Scanned-By: MIMEDefang 2.35 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; cole:99 caml-list:01 ocamake:01 2004:99 2004:99 knowles:99 ocamake:01 interscript:01 camlp:01 camlp:01 interscript:01 simplistic:01 outputs:01 fixpoints:01 outputs:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk skaller wrote: >On Thu, 2004-04-15 at 19:47, Markus Mottl wrote: > > >>On Thu, 15 Apr 2004, skaller wrote: >> >> >>>On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote: >>> >>> >>> >>>>Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle >>>>(1) and (3) all at once. >>>> >>>> >>>Yeah? How would they handle Interscript sources? >>>What about Camlp4? >>> >>> >>No problem, OCamlMakefile handles them by letting the user specify a >>preprocessor in a comment in the first line. See camlp4-example in >>the distribution. >> >> > >That may work for camlp4 but not interscript. >Interscript is a code generator, there is no simplistic >1-1 correspondence between inputs and outputs for which >any make rule could be encoded. > >Make is all wrong, as I said before. Interscript is a new, >correct concept for building systems. It uses fixpoints. >It doesn't care what the outputs are --- they have to be tracked, >but not specified. > > Please forgive my ignorance of interscript but I'm interested in what problem interscript is trying to address. I understand that it makes sense to document code using some simple hypertext language -- something similar to WikiLanguages -- that allows you to make references to code artifacts, include diagrams etc. 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? The way that I now build makefiles is with tcl. set projects { pig } set ml_sources(pig) { one two three } set mli_sources(pig) { two } for y in $projects { # Create .cmo files for x in [get ml_sources $y] { if { [is_member $x [get mli_sources $y]] } { set mli_source $x } else { set mli_source "" } puts "$x.cmo: $x.ml $mli_source.mli" ... } } I find that this approach allows me to factor out the stuff that is repeated between projects and use variables to denote the stuff that changes between projects. This is kind of a moving target because as code develops what is common and what is different between projects changes. Another aspect of configuration management is knowing which libraries a version of your project depends on. There are source level dependencies and after you build libraries there are binary level dependencies. This problem seems to be tackled in two ways: (i) package managers of which godi is a nice example, and (ii) autoconf which alleviates some source level dependencies by hacking the code in sometimes evil ways. Another issue comes to mind. Under linux it seems that libraries have version numbers, libc.so.3.0.0 and the like. I haven't seen how this works with godi? Can you install multiple versions of an Ocaml package and pass version information to Ocamlfind? If not why not? Is the case of multiple deployed library versions something we are striving to avoid? I think for the user it is inescapable, e.g. my desktop requires both gtk-1.2 and gtk-2.0. There is another type of dependency which is very nasty to support and one that I think we should strive to avoid, where possible. The same project supporting quite different build environments. Say for example that you want to want to write a build script that uses either CSH or KSH, whatever is available [1]. Now say that it is not possible to automatically, in general, convert CSH into KSH, so you write a conversion program that doesn't work in general, but works for your build script. This is going to make a difficult to understand mess, it 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. regards, Richard. [1] I'm not advocating the use of build scripts in either csh or ksh just using them as an example. ------------------- 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