From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA29437 for caml-redistribution; Tue, 23 Sep 1997 10:46:26 +0200 (MET DST) 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 QAA25506 for ; Mon, 22 Sep 1997 16:40:44 +0200 (MET DST) Received: from kronstadt.rahul.net (kronstadt.rahul.net [204.95.70.128]) by nez-perce.inria.fr (8.8.7/8.8.5) with ESMTP id QAA12738 for ; Mon, 22 Sep 1997 16:39:43 +0200 (MET DST) Received: (from itz@localhost) by kronstadt.rahul.net (8.8.5/8.8.5) id HAA25511; Mon, 22 Sep 1997 07:38:26 -0700 Date: Mon, 22 Sep 1997 07:38:26 -0700 Message-Id: <199709221438.HAA25511@kronstadt.rahul.net> From: Ian T Zimmerman To: caml-list@inria.fr In-reply-to: <11948.199709171652@jupiter> (message from William Chesters on Wed, 17 Sep 1997 17:52:59 +0100) Subject: Re: ocaml: demand-driven compilation? Sender: weis In message <11948.199709171652@jupiter> (message from William Chesters on Wed, 17 Sep 1997 17:52:59 +0100), you write: > Ian T Zimmerman writes: > > Yes, it would definitely be possible to beef up ocamldep. The > > result would be a reimplementation of make in ocaml. Why > > reinvent the wheel? And why do you dislike makefiles anyways? > > They are the right tool for the job. > There are three things to know in building an executable: what > modules are needed; are they up to date; what commands are needed to > compile/link them? > `make' addresses the second (trivial) point and provides a > framework for going *some* way to help with the third. You have to > bridge the remaining gap yourself. In ocaml (as in Java) this means > duplicating information: the compiler has already used your sources > to find out what modules are needed. Furthermore the task of > inferring what ocaml and native libraries were needed for the link > is easy for the compiler, but a bit annoying for me. > That's why I dislike makefiles. make comes in at the wrong level, > or at least, at a level which was only ever right because C had no > module system worth the name. I disagree. Your argument would be valid if ocaml was the only tool I used in building a program. But what of ocamlyacc and ocamllex? The build process for ocaml itself generates ML files by passing them through the C preprocessor, of all things. Myself, I'd use m4 for that purpose. You could code knowledge of all these file types into ocaml (eeek!) but guess what, I'm considering writing a tree pattern matcher generator, call it ocamlburg. It will obsolete your code immediately. As soon as ocaml is mixed cooperatively with other tools, _all_ of your 3 points become nontrivial and require something close to full make functionality. -- Ian T Zimmerman The dilemma is that when you model something completely on efficiency, a lot of people get hurt. Dr. Leonard Duhl of UC Berkeley, discussing `managed medical care'.