Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!think.com!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!kodak!ispd-newsserver!weimer From: weimer@ssd.kodak.com (Gary Weimer) Newsgroups: comp.unix.programmer Subject: Re: Makefiles -- .c and .h Message-ID: <1990Nov16.171816.7173@ssd.kodak.com> Date: 16 Nov 90 17:18:16 GMT References: <9011151442.AA02010@decpa.pa.dec.com> <1990Nov15.172323.23431@athena.mit.edu> <6268@minyos.xx.rmit.oz.au> Sender: news@ssd.kodak.com Organization: Eastman Kodak Lines: 39 In article <6268@minyos.xx.rmit.oz.au> s887212@minyos.xx.rmit.oz.au (Stephen Riehm [Romulis]) writes: >jik@athena.mit.edu (Jonathan I. Kamens) writes: > > >> The somewhat standard solution to this problem is to create a program or >>sequence of shell commands to parse the source files and determine the >>dependencies on .h files, and to append those dependencies to the end of the >>Makefile (or, in some versions of make, to put them in a file that is included >>by the Makefile). > >This might be the current "standard method" of getting around this >problem.. but wouldn't it be "Better" to "modify" >make / pmake to accept lines similar to.. >.o : .c header.h >or maybe some form of wildcard system? >Is this concept TOTALLY unrealistic. I have found that most of the programs >that I write have only one or two .h files so this sort of structure would >be most reasonable for most of my applications. >Does this also apply to others or am I on my own on this. Does this method imply that all .c files built with this makefile include header.h? This would hardly be practical for large projects. As long as we are modifying make, why not do something a little more robust and automated? 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. Notice that jnk.c does not get recompiled because header.h was changed if jnk.c does not include it. No tinkering with the makefile is needed when new include files are created, or old ones reorganized. Very clean, very sweet.