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 AAA11134; Mon, 6 Sep 2004 00:31: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 AAA12109 for ; Mon, 6 Sep 2004 00:31:54 +0200 (MET DST) Received: from outbound28-2.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id i85MVqqJ032340 for ; Mon, 6 Sep 2004 00:31:53 +0200 Received: from outbound28-2.lax.untd.com (smtp01.lax.untd.com [10.130.24.121]) by smtpout02.lax.untd.com with SMTP id AABAVZE7XAT6NU5S for (sender ); Sun, 5 Sep 2004 15:31:17 -0700 (PDT) Received: (qmail 13877 invoked from network); 5 Sep 2004 22:30:40 -0000 Received: from unknown (HELO vangogh) (4.242.105.170) by smtp01.lax.untd.com with SMTP; 5 Sep 2004 22:30:40 -0000 From: "Brandon J. Van Every" To: "caml" Subject: RE: [Caml-list] Announcing the OMake build system version 0.9.1 Date: Sun, 5 Sep 2004 15:41:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <871xhgflo2.fsf@qrnik.zagroda> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-ContentStamp: 15:7:2518460968 X-UNTD-OriginStamp: CI84cOLHFqh7Zd2QWkwvEFvwyO3T/pIsFsCrOjjLH85cEArEWUqUXQSIzL972Oee X-Miltered: at nez-perce with ID 413B93D8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brandon:99 caml-list:01 marcin:01 'qrczak':01 kowalczyk:01 foo:01 infer:01 expressing:01 gui:01 'make:01 install':01 gui:01 autoconf:01 sln:99 'just:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Marcin 'Qrczak' Kowalczyk wrote: > > My makefiles generally include the following types of information: > > - Rules which tell "how to compile a *.foo file into a *.bar file" > and compiler options. > > - Variable definitions which gather sources from contents of > directories. It's usually "all files with a particular extension > from subdirectories, plus some additions which are generated, > minus some exceptions which are conditionally excluded". > > - Rules which tell which sources and commands to use for many-to-one > targets like programs and libraries, where source names are not > derived from target names automatically because there are many > sources. > > - Administrative rules for things like "make clean" and "make > install". > > All this information is essential for building and impossible to infer > automatically from other files. Another build tool can't eliminate the > need of providing that information in some form. It can only provide a > different language for expressing it. 'Language', by your definition, can include a GUI. Under Visual Studio 2003, when doing C++ projects, the only one I definitely have to mess with is 'make install'. All the other jobs are common enough that I simply don't have to worry about them. Of course, I do have to point-n-click, drag-n-drop to get my source files properly organized. Of course, VS 2003 isn't pain free. I do have to know where various settings are located in the GUI, and it is definitely possible to put settings in a 'wrong' or 'poorly architected' place. It took me awhile to go up this learning curve - but I put far more effort into GNU Make, GNU Autoconf, and IMake, once upon a time. It helps that I have a grungy command line background, that I know this is really all that's going on under the hood. I view VS 2003 .sln files as 'just another kind of Makefile', and they are usually amenable to hand editing. You might argue that the 'language' is really in the .sln file, as it is in a Makefile. Well, the same can be said about Postscript, but end users rarely manipulate Postscript directly. They use tools, because it's too complicated for most users to edit by hand. So, part of the dimension of this discussion, which seems to have the quality of "my build tool is theoretically better than your tool," is how these things behave as *TOOLS*. One dimension of tool quality is how many people use the tool. I hope someone has some insight into my question about OCaml build tool critical mass. > And if I make small changes in one file in order to find some bug, > it's essential to recompile only a few relevant files. How does it > know which other files need to be rebuilt if it does not know *all* > dependencies? Rebuilding everything is out of the question. It should > take 7 seconds, not 7 minutes. And it does with make. In 20..30 years, we will be using cheap, massively parallel computers and exhaustively searching all the available options. These issues will go away. In fact, *lots* of "how do I interface X and Y?" issues will go away, we'll use brute force to glue all kinds of things together. Meanwhile, if you've got enough hardware and a maintainable network, maybe there's some distributed compilation thingamabob available somewhere. Of course, some problems are P-complete, but I'd hazard a guess that trying different permutations in the hope that one is faster in practice is not one of them. > I can't say I like make, but any tool which requires to compile some > files twice, or insists on recompiling everything after a > local change, is not a viable alternative. I'm sure there's probably a gradiated range of tradeoffs available for a tool designer. For instance, brute force could generate a provisional dependency graph, then be reused some of the time, if not all of the time. That might actually work to speed things up most of the time. Cheers, www.indiegamedesign.com Brand*n Van Every S*attle, WA Praise Be to the caml-list Bayesian filter! It blesseth my postings, it is evil crap! evil crap! Bigarray! Unboxed overhead group! Wondering! chant chant chant... Is my technical content showing? // return an array of 100 packed tuples temps int $[tvar0][2*100]; // what the c function needs value $[tvar1]; // one int value $[tvar2]; // one tuple int $[tvar3] // loop control var oncePre eachPre $[cvar0]=&($[tvar0][0]); eachPost $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ ); for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) { $[tvar2] = alloc_tuple(2); $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]); Store_field($[tvar2],0,$[tvar1]); $[tvar1] = Val_int($[cvar0][1]); Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]); Array_store($[lvar0],$[tvar3],$[tvar0]); } oncePost ------------------- 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