gordon@sneaky.TANDY.COM (Gordon Burditt) (02/27/89)
In article <9727@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >It's easy to get the Makefile correct; just declare that a header >depends on the others that it #includes. Gack!! Please, I hope that you meant that the resulting object file depends on all the headers that are included, directly or indirectly, not: foo.o: foo.c header1.h header1.h: header2.h Unless you are building header files on the fly (yacc does it, gcc does it, and a few other programs do it, but not many), having one header file depend on another file is a nuisance, and wrong. If you get the relative times of the two header files wrong, you will recompile things that depend on the header files every time you do a make. It is NOT necessary to rebuild header1.h if header2.h changes. Then someone "improves" on it with: header1.h: header2.h touch header1.h This often has the problem that the touch fails due to no write permission on header1.h (it's mode 444 because it was checked out without intent to edit), or, by including this rule, the automatic checkout rules (from SCCS or RCS) don't function, giving you an empty header1.h instead of checking it out. Most of the various automatic dependency generators handle nested include files fine, although they vary a bit on how they handle CONDITIONAL inclusion, (especially conditional non-inclusion of USG files on BSD systems & vice versa). For example, "gcc -M -DUSG *.c" will output something similar to: (assume header1 includes header2, and foo.c and baz.c don't include header2.h directly) foo.o: foo.c header1.h header2.h bar.o: bar.c header2.h baz.o: baz.c header1.h header2.h header3.h (and only show dependencies on include files used, so including all the -D and -U flags that it will be compiled with is necessary to get accurate results). Gordon L. Burditt ...!texbell!sneaky!gordon