Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!hamish
From: hamish@unisoft.UUCP (Hamish Reid)
Newsgroups: comp.unix.wizards
Subject: Re: 'nmake'
Message-ID: <2062@unisoft.UUCP>
Date: 24 May 89 15:55:05 GMT
References: <1989@internal.Apple.COM> <11570@ulysses.homer.nj.att.com> <2060@unisoft.UUCP> <11581@ulysses.homer.nj.att.com>
Reply-To: hamish@unisoft.UUCP (Hamish Reid)
Lines: 56

In article <11581@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes:
>
>The need for these is that the make model is too simplistic: As I said
>before, time stamps are not good enough to determine when a file should
>be recompiled. When projects get too big, the makefiles get too complicated
>and one is never 100% sure that make is recompiling all the files it REALLY
>needs to and that it's not compiling too much.

Fine. If it actually worked that way. With nmake's poor documentation
and inscrutable syntax, there was a long time during a recent project
when we were almost always 100% sure that nmake was *not* recompiling
the correct things. Nmake was simply too hard to understand and use in
almost all situations - a tool like nmake should, above all, be
*trustable*. Trust comes from understanding. Understanding (tends to)
come from simplicity, clarity, and compatibility with past paradigms.
The versions available was/is none of these, mostly due to bugs
(presumably fixable), a (IMO) tendency to try to solve every problem
with the one program, and the terse and difficult syntax.

The issue here is *overall* effectiveness and efficiency. I have no
trouble with co-shells, the idea of a generalised make engine, etc.
It's just that our experiences with the actual implementation were
uniformly bad.  We noticed that nmake bugs and problems derived from
the combination of paradigm confusion and complexity, opaque syntax,
and poor documentation, accounted for a significant proportion of the
development and testing time on one of our larger recent projects. My
personal estimate is that we spent perhaps 10-15% of our engineering
effort towards final release in nmake-related bug fixing - suddenly the
libraries wouldn't compile, or nmake decided that something was
out-of-date when it wans't (or vice versa), the rules were subtly wrong
but almost incomprehensible so we had to appoint an nmake guru who
became a bottleneck for the project, etc etc. At least with make
dependecies were simple and well-documented, (almost) always explicit.
I know the problems with make - but they were always well-understood
and usually easy to work-around.

Nmake is (perhaps) a good idea. For software engineering reasons,
though, I would currently prefer something simpler, more focused on
doing-one-thing-right, and more understandable - especially in a tool
that is crucial to project success. Then again, I would prefer an
entire IPSE-like system, but ....

I will never willingly use nmake again on any project unless we can be
convinced that it has been fixed, and that there are no better tools
available. We will probably go back to make or MAKE or mk or whatever -
at least yer average injuneer can both understand and trust them.

Please, if there is a better nmake available, let us all have it,
evaluate it, and maybe use it the way it was intended. If it isn't
available, there isn't much use talking about it here - we are
unfortunately limited to talking about what's available.

	Hamish
-----------------------------------------------------------------------------
Hamish Reid             UniSoft Corp, 6121 Hollis St, Emeryville CA 94608 USA
+1-415-420-6400         hamish@unisoft.com,         ...!uunet!unisoft!hamish