Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!abvax!iccgcc!browns
From: browns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems)
Newsgroups: comp.lang.c
Subject: Re: C + Make
Message-ID: <852.26ed037c@iccgcc.decnet.ab.com>
Date: 11 Sep 90 20:32:10 GMT
References: <BEVAN.90Sep10220041@rhino.cs.man.ac.uk>
Lines: 74

In article <BEVAN.90Sep10220041@rhino.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
> If you have .h files that include other .h files, such as the
> following :-
> 
> /* foo.c */
> #include "foo.h"
> 
> /* foo.h */
> #include "a.h"
> #include "b.h"
> 
> /* a.h */
> lots of #includes
> 
> /* b.h */
> lots of #includes
> 
> then inorder to get `make' to update foo.c if anything in the headers
> change, you have to do something like :-
> 
> foo.o:	foo.c foo.h a.h b.h ... any file that a.h/b.h includes
> 
> i.e. you have to flatten the hierarchy you have built up.
> 
> What I'd like to know is there any way of writing this as :-
> 
> foo.o:	foo.c foo.h
> foo.h:	a.h b.h
> 
> a.h:	a.h' includes
> b.h:	b.h's includes
> 
> i.e. maintaining the hierarchy, but so still forcing foo.c to be
> recompiled if one of a.h/b.h (or its includes) changes.

[sound of throat clearing]  This might go better in one of the
comP...programmers or comp.os... groups, because it depends on _which_
kind of MAKE you're using.  MAKE is definitely not part of C, and there
is no standard that I'm aware of.  So the following answer might
possibly not work with your version of MAKE.

Now that I've explained why I shouldn't attempt to answer your question,
here's my answer.  :-)  Here's how I've attacked it in the past.  This
works for IBM's MAKE with C/2 (therefore presumably for Microsoft C 6.x)
and for MMS in VAX/VMS.

In the description file, define a macro for each of the bottom-level
header files:

PRIM_H   = prim.h
PROPER_H = proper.h

Then for the "composite" header files, the macro wouldd include the file
itself and the _macro_ for its first-level dependents:

MIDLEVEL_H = midlevel.h $(PRIM_H) $(PROPER_H)
A_H = a.h $(MIDLEVEL_H)

foo.obj : foo.c $(A_H)

The trick is _never_ to use an explicit header file name on the right
side of a dependency definition; always use the corresponding macro.

The technique is also useful when the header files are scattered through
different directories as well.

BTW, why are the components called "dependents"?  Seems to me that the
target is the dependent because it depends on the components.


Stan Brown, Oak Road Systems, Cleveland, Ohio, U.S.A.         (216) 371-0043
The opinions expressed are mine. Mine alone!  Nobody else is responsible for
them or even endorses them--except my cat Dexter, and he signed the power of
attorney only under my threat to cut off his Cat Chow!