Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!hector!ekrell
From: ekrell@hector.UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: 'nmake'
Message-ID: <11581@ulysses.homer.nj.att.com>
Date: 22 May 89 23:54:58 GMT
References: <1989@internal.Apple.COM> <11570@ulysses.homer.nj.att.com> <2060@unisoft.UUCP>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: ekrell@hector.UUCP (Eduardo Krell)
Organization: AT&T Bell Laboratories
Lines: 91

In article <2060@unisoft.UUCP> sparker@unisoft.UUCP (Steve Parker) 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.

I don't understand.  What is it that bothers you: that nmake will be offered
and people will have a chance of using it?  You have a right not to use it
if you chose not to, but why shouldn't others get to decide if they like it
or not?

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

The need for these is that the make model is too simplistic: As I said
before, time stamps are not good enough to determine when a file should
be recompiled. When projects get too big, the makefiles get too complicated
and one is never 100% sure that make is recompiling all the files it REALLY
needs to and that it's not compiling too much.

On a small system, this might not make a big difference, but on a big
project where building the system takes a day of CPU time or more,
it's critical that this process be as efficient and as reliable as
possible.  Many of the projects using nmake now have cut their building
times because back when they used make, they had to rebuild everything
from scratch as they didn't trust make to do the right thing.

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

But what bothers you: that he did succeed in doing that? Are you annoyed
that someone can write a general purpose make engine which can be tailored
with higher level rules?

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

First of all, you can turn off source scanning if you want. And, anyway,
source files are rescanned only if they've changed since the last time
they were compiled, so you're clearly exaggerating the overhead.

And it doesn't do the wrong thing for #include's within #ifdef's:
it knows about them and it doesn't require the included file to
be there.

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

Depends on the version of nmake: you're talking about a 4 year old piece
of code which we haven't been allowed to update. nmake 2.0 is a complete
rewrite and it's being used by lots of internal AT&T projects, all sizes.

I've rewritten the Unix kernel makefiles to a single nmake makefile.
It went down from about 40 pages of makefile to 1.5 and the system
can be recompiled much faster now.

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

How about the use of a co-shell so that individual actions don't need
to spawn new shells all the time?
How about having compiled makefiles so that they don't need to be reparsed
every time you run make? How about binding of source and header files so
that if you add a different include or source directory which changes the
binding of some source/header file names, nmake will recompile whatever
needs to? How about using a state variable so that if you change its
value in the Makefile, all the files which use that symbol will be
recompiled (with the new -D flag)? How about using .SOURCE rules
to specify lists of directories where different kinds of source and
header files are and let nmake generate the right -I flags and compile
source from those directories?

The list could go on, but I've already made the point.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

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