Version française
Home     About     Download     Resources     Contact us    
Browse thread
ocaml: demand-driven compilation?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Ian T Zimmerman <itz@r...>
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'.