Re: ocaml: demand-driven compilation?

From: Ian T Zimmerman (itz@rahul.net)
Date: Mon Sep 22 1997 - 16:38:26 MET DST


Date: Mon, 22 Sep 1997 07:38:26 -0700
Message-Id: <199709221438.HAA25511@kronstadt.rahul.net>
From: Ian T Zimmerman <itz@rahul.net>
To: caml-list@inria.fr
Subject: Re: ocaml: demand-driven compilation?

In message <11948.199709171652@jupiter> (message from William Chesters on
        Wed, 17 Sep 1997 17:52:59 +0100),
you <williamc@dai.ed.ac.uk> 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                        <itz@rahul.net>
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'.



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:12 MET