'nmake'

[Steve Parker]

In article <11570 at ulysses.homer.nj.att.com>, ekrell at hector.UUCP (Eduardo Krell) writes:
> 
> As I said before, I don't know whether the new nmake will be offered
> through the Toolchest or with SVR4, but the bottom line is that it
> will.

I am truly sorry to hear that.  I'm convinced it's the wrong tool for the job,
encourages complicated solutions to problems, and has extremely poor compatiblity
with its predecessor.

Back in college, I was told a number of times how many students leave school wanting
to write a hot new operating system, and a hot new compiler.  Nmake strikes me as
an example of exactly this disease.  Nmake has an odd programming language, with
a complicated, ill-defined paradigm to describe the class of problems it intends to
solve.  It seems to me to have been bred to "solve all the world's problems" -- A
very old human folly.

The whole reason 'make' was a win in the first place was that it found a simple
paradigm for describing how to regenerate software:  Files depend upon one another,
and a simple set of steps record how to bring a file up to date.  Can anyone state
in one or two sentences what nmake's paradigm is?  I sure can't.  There are file
dependencies, state variable dependencies, attributes, ...  Ugh.

To rattle on a bit more, the following is from "The Fourth Generation Make", by
Glenn Fowler, from the summer USENIX in Portland:

	"As a testimony to the strength of this metalanguage, most new make
	features and ideas have resulted in changes to the standard builtin rules
	(written as a makefile) rather than in changes to the [nmake source]."

This statement bothers me.  It reminds me of saying "Ada is the perfect programming
language, because you can do _anything_ with it."  (Substitute for Ada your favorite
over-burdened, complex language.)  It makes me suspicious of the authors:  Do they
know when to quit?  I doubt it.

One particular nmake gripe I have has to do with its scan for implicit dependencies.
(I don't want 'make' knowing how to scan C files for dependencies, anyway.  That should
belong to a separate tool, but let's forget that for a moment.)  In an attempt to make
nmake fast enough to be a satisfactory tool, one optimization was to make scanning
C files for '#include' dependencies built into the nmake code.  This saves fork/exec
of /lib/cpp don't you see?  Of course, all it does is essentially:

	egrep '^#[ \t]*include'

This does the wrong thing for some #ifdef'd source.  It still makes nmake slower
than it need be, and wrong to boot!?!?

> 
> Remember, Toolchest programs are totally unsupported. You're expecting
> too much from something that didn't promise anything.
>     
> Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

Been hanging out with the lawyers lateley?  "No claim is made about fitness
for any purpose whatsoever."

I know nmake doesn't come with any claims.  I guess I just have the idealistic hope
that a responsible engineer doesn't let a buggy, untested piece of software loose
on the world.  And I look at AT&T, who charges money for nmake, and expect that
they would be concerned about their reputation.  They would send it out in a form
that works pretty much.  Silly me.

And even if it _were_ completely free, unsupported software, there is nothing wrong
with calling a spade a spade.  People are doing exactly this.  Or are there hoards
of people who are happy and pleased with nmake out there?

To decide if a tool is successful, one criterion is how many people seek it out to
help them.  Is it "part of the furniture"?  Patch and tons of GNU software are great
examples of good software tools.  They work, and they do useful things.  Some vendors
ship GNU sources on their systems because so many of their customers use it.

In my opinion, nmake is not such a success.  I have had to eliminate from my
software development.  I was unable to justify the amount of overhead it involved,
versus the benefit over make.  (The only benefit I derived from nmake was the "-j",
parallel job option.  All the rest of the 'features' did not do anything constructive,
or at least not constructive enough to justify itself.)

No nmake!

Steve Parker
sparker at unisoft.com
{ucbvax,sun,uunet}!unisoft!sparker
----------------------------------
"Start your own revolution, and cut out the middle man"   --Billy Bragg