Bugs in the AT&T Toolchest program 'nmake'

[Michael McNamara]

In article <11562 at ulysses.homer.nj.att.com> ekrell at hector.UUCP (Eduardo Krell) writes:
|In article <6561 at ardent.UUCP> mac at mrk.ardent.com (Michael McNamara) writes:
|
|>	I would strongly suggest that you get your money back from
|>AT&T for nmake, and get gnu-make from the Free Software Foundation.
|
|Why would you want to do that? nmake is much more powerful than
|gnu-make.
|
|>	nmake is 1) quite buggy, and 2) does not use standard
|>makefiles.
|
|That particular version of nmake being distributed by the Toolchest
|might be buggy, but newer versions are not.
|
	Where would you get these? how much *MORE* would they cost?
What address might you report bugs to?

|Of course it doesn't use standard makefiles: they specify too much
|details. nmake makefiles are smaller by an order of magnitude.
|
	Gnu-make also supports much smaller makefiles, by providing
a richer set of builtin rules.  Gnu-make also supplies builtin rules for
documentation tools, an important part of any project development.
	Gnu-make further supports gnu-emacs generic development environment, 
giving error messages which are complete (with directory) to facilitate 
emacs's next-error function.

	All these new features leverage off the thousands of human hours which
have gone into creating Make trees.

	Nmake tells you to throw all those away and use the new system.
In processor design a rule of thumb is that if you do not provide 4x
performance increase, you must provide backwards compatibility.  Users will
not 'make' so extensive a switch unless it gives them large rewards.
	What Nmake provides is not enough for me to convince my company to 
switch. 
( My last company switched to nmake, and they're OUT OF BUISINESS :-) :-) :-)
  Cydrome... Another new technology that wasn't 4x the standard offering...
  [I couldn't resist... The implication that nmake had anything to do with
   cydrome's demise is greatly exagerated and heavily :-)'ed ]

|>	gnu-make is 1) free, 2) can use standard makefiles 3) has the
|>multiple jobs, load average sensitivity and other featues of nmake.
|
|But can gnu-make prevent you from running simultaneous yacc jobs
|on the same directory? This wouldn't work as yacc uses a fixed file

	bison, gnu's replacement for yacc, is upwardly compatible with
standard yacc syntax, with the addition of the feature that file.y produces 
file.c by default (there is a switch to revert to yacc's fixed file name).  
bison also has a hairy mode (called bison.hairy..) that supports error 
recovery and limited look ahead.
 
|name (y.tab.c) which would be overwritten by the multiple yacc's
|(yes, nmake does know about yacc and other tools which can't be run
|in parallel).

	Further, these `other tools' following yacc's baroque (sp?) 
behavior could have explicit dependcies described in the Makefile, in
a manner that any make program could understand.

|
|>	gnu-make also has non standard makefile extentions, but you
|>do not need to use them to get the power of parallel make, which is
|>what I consider to be the main virtue of nmake & gnu-make.
|
|The parallel jobs facility is not the main virtue of nmake. The main
|virtue of nmake is that it uses a statefile to record what it does
|and it doesn't just rely on time stamps on the files to determine
|whether they need to be recompiled or not. This guarantees that
|all (and only those) files which need to be recompiled will be.
|
	This is nice, and is a definate step forward in make technology.
Although I will note that it many times got in my way. I find myself, when 
using regular make, doing things like: "touch `grep -l MAXSIZE *.c`; make"
when I change the definition of MAXSIZE in some header file. nmake (perhaps
quite correctly) would not let me get away with those shenaigans. (It would
insist on compiling every file that included the .h file that I changed...) 
Nmake does have a -A switch, which causes it to ignore it's statefile; I 
used this to effect my touch trick above. 

|Other big wins:
|
|* The implicit dependency on #include'd files (which nmake finds
|  out on its own).
| 
	See above... further, gnu-make supports included makefiles, enabling
make-depend and cc -M to work.

|* Automatic generation of -I flags for the compiler for each source
|  file to look in the right directories where header files are.
|
	I'm not sure what you mean by this... With every cpp I am aware of, 
if the .c file says #include "/usr/foo/dz.h" you don't need a -I; if it 
says <sys/reg.h> you don't need a -I; if it says "limit.h" you don't need 
a -I.  The only time you need a -I is when you want it to get <sys/reg.h> 
from /cross/I860/sys/reg.h, or some such, and how can nmake know that? 
If you say from the environment, most makes let you do this; If you say 
from a base project makefile, sysV, sun and gnu-make let you do this.  I am 
perplexed by what you mean.

|* The use of global makefiles with rules tailored to a particular
|  environment/project.
|    
   Many makes allow superior makes to pass environments to children makes;
what nmake does can be done this way (although, perhaps not as cleanly). 

|Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ
|
|UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell at ulysses.att.com

So in conclusion, gnu-make offers the parallel make feature, but not the
Makefile.s state file of nmake.  gnu-make is free, has a mailing list for bug
reports/fixes, and is distributed widely. Further, you can use gnu-make as 
a replacement for /bin/make, add a MAKEFLAGS=-j3 to your environment, and
recompile your entire source tree, without changing all you makefiles. (it
would help if you had a multiprocessor machine. (gnu-make does support remote
compilation, so you guys with 20 3/50's with a common nfs mounted directory can
exploit your available parallelism)) 

Further, if you stumble upon a gnumake bug, you can still ship your code 
using /bin/make.

Nmake has a complicated additional feature, and costs $$.

_________________
Michael McNamara 
  mac at ardent.com