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 RAA27584; Sun, 5 Sep 2004 17:53:37 +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 RAA28361 for ; Sun, 5 Sep 2004 17:53:36 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i85FrX1I032661 for ; Sun, 5 Sep 2004 17:53:35 +0200 Received: from [192.168.1.200] (ppp210-32.lns2.syd3.internode.on.net [203.122.210.32]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i85FrS4Y019197; Mon, 6 Sep 2004 01:23:29 +0930 (CST) Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 From: skaller Reply-To: skaller@users.sourceforge.net To: "chris.danx" Cc: David Brown , caml-list In-Reply-To: <413B2BCB.3030000@ntlworld.com> References: <4139ECD3.1050708@cs.caltech.edu> <001e01c492a6$872c7280$19b0e152@warp> <413A0921.7030607@ntlworld.com> <413A1E89.10806@libertysurf.fr> <1094361655.3352.476.camel@pelican.wigram> <20040905132006.GA15531@old.davidb.org> <413B2BCB.3030000@ntlworld.com> Content-Type: text/plain Message-Id: <1094399607.3352.679.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Sep 2004 01:53:27 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 413B367D.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 someway:01 dependencies:01 outputs:01 outputs:01 dependencies:01 9660:01 glebe:01 chris:01 lib:01 nsw:01 snail:02 makefile:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2004-09-06 at 01:07, chris.danx wrote: > David Brown wrote: > > - They tend to be very tied to their specific language. When source > > files in this language are themselves generated, this either has to be > > encoded in the make tool (yuck), or the make tool wrapped in a > > makefile, which kind of defeats the purpose. > > I don't understand what you mean by this, but surely having a tool for > the most common purposes is better than no tool at all. That may be so, but can we do better? I mean, programmers are always trying to automate things better, that's what our job is. > Gnatmake builds the > library but the library needs to exist before you can build the rest of > the program so you need someway to tell it to biuld the lib first. No you don't! You're making an assumption about build processes that specifying dependencies is fundamental. But that isn't the case. Here is a perfectly viable build script: build program build library You think that will work? It sure does! Here is the driver: limit = 10 run build while (--limit && new_outputs != old_outputs) run build This isn't efficient but it works *without* specifying dependencies or the correct build order. If you want it to be faster -- specify the component builds in the right order :) Point being -- getting the right order is an optimisation. > Ada has the elaboration problem and it is up to the programmer to solve. > :) The programmer needs to know the elaboration order they want in > order to get the program to work. If there are elaboration issues the > programmer must solve them themselves unless the tool can sort them out > for them. I see no problem with this. The problem is that the current technique for solving the ordering problem is to compile and link libraries in a particular order -- in other words, hand write the build script instead of generating it. However if the source code contained enough information, the build scripts could be generated automatically. -- 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