Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!gsf
From: gsf@ulysses.homer.nj.att.com (Glenn Fowler[drew])
Newsgroups: comp.unix.wizards
Subject: Re: Bugs in the AT&T Toolchest program 'nmake'
Summary: clarification
Message-ID: <11574@ulysses.homer.nj.att.com>
Date: 22 May 89 13:13:55 GMT
References: <1640@internal.Apple.COM> <6561@ardent.UUCP> <24658@agate.BERKELEY.EDU>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 79

This is in response to the recent nmake chatter.
A summary of the (negative) articles on the 8/85 ToolChest nmake:

(1) it has a lot of bugs
(2) it has bad coding style
(3) it has lousy documentation
(4) it is incompatible with mymake
(5) it should be free
(6) it should compile on mynix
(7) it does too much

I'll refrain from discussing what is internally available to AT&T and
instead focus on the 8/85 ToolChest nmake.

(1) The 8/85 ToolChest nmake was developed (by me) over a 8 month period
in 1985.  This was the first widely distributed version, both inside and
outside AT&T.  For various reasons, all out of my control, internal fixes
and changes never made it to the ToolChest.  This is unfortunate.  We are
comparing a program frozen in 8/85 to a 1989 environment.  I even have
trouble understanding that old code.  Some of the bugs are from undetected
NULL pointer dereferences (work was mainly on a 4.2BSD vax).  These bugs
were nasty as they sometimes propagated into the state file and affected
later versions that already had the bugs fixed.  Other bugs came from hasty
implementation.  There are many themes running through nmake (shell interface,
rule language, persistent state, makefile `compilation', dynamic dependency
generation), some more important than others.  The important ones received
the most attention.  As a whole, nmake was exercised more intensly than
anticipated, magnifying the weak parts of the code.

(2) This comment is closely related to (1) and was based on ``each bug fix
adds n new bugs''.  nmake is a sequential machine that roams about global
declarative data structures.  A local change to one part of the structure
easily affects remote parts of the code.

(3) Agreed.  As I remember the documentation consisted of a README and
a man page.  The man page was not an appropriate format for the entire
nmake description.  However, at the time it was the best way to get the
information out.

(4) Early on I discovered that I would be spending 90% of my time avoiding
incompatibilities.  The code and data would become more twisted, and, more
importantly, I would have lost interest in the whole thing.  I took the
best concepts from make and dropped the arbitrary implementation details.
An observation: there are a handful of popular variants now, all compatible
with a `make' that existed 10 years ago.  The only new feature that all
agree on is the pattern metarule (e.g., %.o : %.c).  Using any of the
other new features is inherently incompatible.

(5) I won't even touch this one.

(6) nmake uses many os-dependent features (dup2, close fd-on exec,
signals, process group control, reading directories, etc.).  These
features were detected by a monster installation script that was very
sensitive to error.  This script also had to be restarted from the top.
These problems aside, such scripts are still limited to the knowledge of
the different os-dependent feature implementations.  I had access to
4.2BSD vax (the home machine), system V on 3B2's and 3B20s, unixpc,
apollo, sun and handled these.  Other variations were at the mercy
of the monster script.

(7) I still wrestle with this one.  nmake set out with these goals:

	(a) add state to increase the scope of `up to date'
	(b) add constructs that avoid makefile redundancies
	(c) add support for dynamic dependency generation (e.g., #include's)
	(d) support concurrent action execution
	(e) do all of this efficiently

Early implementations tackled these brute force.  Some of the details
were too visible.  Later versions do a better job of layering.  Most
of the complaints about ``too many *nix assumptions'' and ``do it
nmake's way or else'' are actually in the realm of the global rules
rather than in the guts of the C code.  Granted, the global rules
were hairy, but they can and have been changed.

I'll be glad to discuss the current nmake off-line and summarize to the net.
-- 
Glenn Fowler    (201)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,decvax,ucbvax}!ulysses!gsf       internet: gsf@ulysses.att.com