Makefiles -- .c and .h

[Jonathan I. Kamens]

In article <6268 at minyos.xx.rmit.oz.au>, s887212 at minyos.xx.rmit.oz.au (Stephen Riehm [Romulis]) writes:
|> This might be the current "standard method" of getting around this
|> problem.. but wouldn't it be "Better" <totally subjective term> to "modify"
|> make / pmake to accept lines similar to..
|> .o : .c header.h
|> or maybe some form of wildcard system?

  That's just fine if every one of your source files includes the same header
files, but in a large software project, that is almost definitely not the case.

  Recompiling is a slow process; I want it to take place *only* when
necessary, which means that I only want dependencies for each .o file to exist
for the actual include files upon which that .o file depends, not for every
include file in the software project.

  Another reason automatically generated dependencies are a good thing is that
they do recursive dependency generation.  That means that if I include
<X11/Xlib.h>, and that file includes <X11/X.h>, then both of those include
files will be added as dependencies.

  Some people see this as a bad thing; they say, "Why should I have to
recompile everything if my administrator changes <stdio.h>?"  My answer is
that if any standard system include file was changed, there's a *reason* for
it, and you should be recompiling if for no other reason than to verify that
your source code still works with the changed header files.

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