Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.programmer
Subject: Re: Makefiles -- .c and .h
Message-ID: <1990Nov18.204706.7044@athena.mit.edu>
Date: 18 Nov 90 20:47:06 GMT
References: <9011151442.AA02010@decpa.pa.dec.com> <1990Nov15.172323.23431@athena.mit.edu> <6268@minyos.xx.rmit.oz.au> <1990Nov16.171816.7173@ssd.kodak.com>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 25

In article <1990Nov16.171816.7173@ssd.kodak.com>, weimer@ssd.kodak.com (Gary Weimer) writes:
|> SunOS's make has the "special-function target":
|> 
|> .KEEP_STATE:
|> 
|> which causes make to keep a record (in the file .make.state?) of which
|> include files each .c file uses (amoung other information). When make
|> is invoked after changing only one of these include files, make will
|> catch this and recompile the appropriate .c files. If a .c file is
|> changed, it needs recompiled anyway and a new list of include files
|> is generated.

  How does the SunOs make figure out which files were included by each source
file?  Does it do a "cc -E" on the source file, or something similar?  If so,
isn't that (a) slow since it has to do it again each time the .c file changes,
and (b) a problem with source files on which "cc -E" (or whatever command make
uses) won't do the right thing?  It seems to me that you're introducing a lot
of complexity into make, and it isn't clear to me that it can do the job
correctly and reliably.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710