On 10-Jun-1999, D. Tweed <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jun 1999, Craig Dickson wrote:
>
> > If it seems desireable
> > to re-implement a standard Unix utility in Haskell, I suggest 'make'. One
> > could even design and implement a 'make' that would know all about Haskell
> > modules, and parse them to generate dependencies automatically.
>
> I think it'd probably better software engineering to split the two tasks.
> Other than a rather nasty syntax, make does what it sets out to do quite
> well: using specified dependencies and time-stamps on files to run
> `compilation-type' processes in an appropriate way.
I agree the tasks should be split, but I have to object to any claim that
standard Unix make does its job well. Standard make has a number of
severe flaws over and above its nasty syntax -- lack of programmability,
no support for dynamic dependencies, no support for conditional inclusion,
lack of support for transitive dependencies, lack of support for makefile
code reuse, very limited support for polymorphism or abstraction,
lack of static checking (e.g. mispelt variable names are silently ignored),
and so on. All of these are very important for "compilation-type processes".
More modern make programs, in particular GNU Make, certainly do a better job.
But even GNU Make still suffers from nasty syntax, lack of programmability,
limited support for dynamic dependencies, and inefficient and cumbersome
support for datestamp files to avoid unnecessary rebuilding, and a few bugs.
(GNU Make does however support parallel make, and this feature is sufficiently
important, and sufficiently difficult to program, that writing a improved
replacement for GNU Make would be a fairly significant amount of work.)
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
