Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!agate!homer.Berkeley.EDU!mcgrath
From: mcgrath@homer.Berkeley.EDU (Roland McGrath)
Newsgroups: comp.unix.wizards
Subject: Re: Bugs in the AT&T Toolchest program 'nmake'
Message-ID: <24658@agate.BERKELEY.EDU>
Date: 21 May 89 00:32:18 GMT
References: <1640@internal.Apple.COM> <6561@ardent.UUCP> <11562@ulysses.homer.nj.att.com> <MCGRATH.89May19190412@paris.Berkeley.EDU> <11564@ulysses.homer.nj.att.com>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: mcgrath@homer.Berkeley.EDU (Roland McGrath)
Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome)
Lines: 65

["Bugs in the AT&T Toolchest program 'nmake'"] - ekrell@hector.UUCP (Eduardo Krell):
) In article <MCGRATH.89May19190412@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
) 
) >What I know of nmake is only the things you have mentioned.
) >But it seems to me that nmake is, in fact, LESS powerful than GNU Make.
) 
) Since you haven't used nmake, shouldn't you at least read the manuals
) before you try to compare it to any other make? It seems fair to me.

If AT&T wanted me to be able to make a fair comparison, they ought to
give me the manuals, and the product itself, to examine for free.
It seems fair to me.

) >GNU Make allows much smaller makefiles too, but can accept old makefiles as
) >well.
) 
) OK, here's an nmake makefile for a command "foo" which is built from
) 2 C files (x.c and y.c) and a yacc file z.y; it also uses a library
) called "libfoo.a" which is built from foo1.c, foo2.c and a lex file gram.l.
) 
) foo :: x.c y.c z.y -lfoo
) 
) libfoo.a :: foo1.c foo2.c gram.l
) 
) (nmake takes care of generating .o's from the .c's, .y's and .l's
) and archiving foo1.o, foo2.o and gram.o into libfoo.a.  In addition,
) the .c files are searched for #include statement so those dependencies
) need not to be mentioned.
) 
) Can't get any smaller than that, can it?

Not much, it's true.
To get the right results from GNU Make, however, you have to say what you
mean.  foo and libfoo.a must depend on the .o files, unless the new AT&T
linker handles C, Yacc, and Lex itself.

) >This is nmake's main *selling point*.  Whether such incredible hairiness is
) >a `virtue' is highly debatable.
) 
) So where you're example of why this wouldn't be a "virtue"?. Depending
) on just the time stamps to decide whether a file needs to be recompiled
) or not is simply unreliable. If you still don't see why, I can provide
) you with plenty of examples.

My statement was the example.  Hair, fluff, goop, etc.

) >GNU Make is very flexible; it is not limited to the applications its
) >authors had in mind.
) 
) This shows you know nothing about nmake. The features I mentioned
) are not part of the nmake engine but are part of the "makerules"
) which can be customized or changed for some other application.

Then they appear to be on the same level in this regard.

) >This is not very clear, but if I understand what you're talking about, GNU
) >Make can do that too.
) 
) No, it can't. Read the nmake documentation.

No, I can't.  Give it to me for free and I will.
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland
Copyright 1989 Roland McGrath, under the GNU General Public License, version 1.