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

In article <2066@unisoft.UUCP> sparker@unisoft.UUCP (Steve Parker) writes:

>Let me see:  The
>most reliable way to regenerate software is to recompile the whole world
>every time.  (No errors or variability are possible.)

With old make (and any other versions of make wich relly only on time
stamps), yes.

> Efficient is 
>recompiling only the absolute minimum number of files.  Sounds like
>these are trade-offs to me.

With old make, yes.  This is one of the advantages of nmake: that
you get both reliability (by having a state file and not depending on
just comparing time stamps) and efficiency (by not having to recompile
more than is needed).

>No.  I have always been able to get make to do pretty damn close to anything
>I want.

Please tell me how you get make to do the right thing when you replace
either your source of header files with different versions whose time
stamps is still older than the corresponding .o's ?

>Based on my experiences, it was not a success.

And based on my experience (and the hundreds of nmake installations
within AT&T), it was.

>Interesting.  After I'ld reached the point of having burned three weeks
>of my time on nmake bugs with a kernel nmake file, I converted it to
>a make file.  It was less than 10% larger than the nmake file.

This shows you didn't know how to take advantage of nmake. All the
makefiles I've converted to nmake have been reduced by about an order
of magnitude.

> While I haven't
>made measurements, my feel is that make is about 30% faster at figuring
>out if anything needs to be made.  And it recompiles the right things
>every time now!

Does it? See the example above.

>How about a shell script that takes the name of a variable I've changed,
>uses grep to go through source files looking for actual dependencies on
>that variable, and touching only _those_ files?

Then you'll have to tell that shell script which variables have changed.
Why? I just want to change the symbol in my makefile and let nmake
figure out what needs to be recompiled.

>Path searching for source files is available in numerous makes.  Many
>of them are predictable and reliable.

I don't know of any other version of make which generated -I flags
based on what each source actually includes (instead of issuing all
the -I flags to all the source files).

>In my opinion nmake is a bad idea, poorly done.

And in my opinion nmake is a great program. It takes guessing out
of the software building process.

>Nmake isn't simple.

Who said it is? It's not solving an easy problem. It can't be
simple because the rules for building systems in a Unix/C environment
are complex.

> Putting features like scanning C source files for
>dependencies is a poor cost/benefit decision.

I'd like to know how you can do the same thing more efficiently.
I don't want to manually list every header file I include (the
transitive closure, actually) in my makefile, yet I want my
file to be recompiled whenever one of those header files is changed.

> Nmake's design reflects
>an attempt to design with _all_ possible customers in mind.

Nonsense. It was designed to do the right thing in a Unix/C environment
(which is the standard development environment at AT&T).

>In my opinion, nmake is a poorer tool even than make.  And other new
>makes have a less confusing, more sensible view of the world.  (e.g.,
>mk and GNUmake)

I don't know how big a project you've been working, but for big projects
with thousands of files and hundreds of makefiles, make's simple model
isn't good enough.

I suggest we take this discussion off-line since it's getting too
boring.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

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