Bugs in the AT&T Toolchest program 'nmake'

[Eduardo Krell]

In article <MCGRATH.89May19190412 at paris.Berkeley.EDU> mcgrath at 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.

>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?

>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.

>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.

>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.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell at ulysses.att.com