C + Make

[Wayne Throop]

> From: grimlok at hubcap.clemson.edu (Mike Percy)
> If you want to make your makefile reflect the include heirarchy try
>    [.. having "make" steps that touch ".h" files ..]
> This does have the side effect of perhaps changing the time stamps on
> a,h and b.h when their contents haven't changed, but I don't mind that.

There are problems with this method.  Mike may not mind them, but

  1) You lose last-edited time information.  (This may well be moot if 
     you keep audits in comments or seperately.)
  2) Other tools that keep track of timestamps or use timestamp+filename
     as a UIDlet can get confused.  Eg, archiving or "file motel" systems.
  3) It is not quite an accurate description of the situation to make.
     For example, if processes other than compiles read the .h files,
     especially processes that don't follow #includes (Eg: automatic
     documentation generators) this would provoke much extra work, since 
     THIS .h file didn't really change, just THAT one over there.

> You might leave off the touch commands...I'm not sure how that would
> work.

It wouldn't work.

But having bitched, I can propose an alternative.  The problem is that there
is a pseudo-object which is all-the-include-files-recursively-reached from
any given node.  So, what I do (have done) is represent the time currency
of this state of affairs with an empty file (to store the timestamp).

For a situation where b.h includes c.h, and a.c includes b.h and c.h,
the rules go something like

     a: a.o
     a.o: a.c b.h+i c.h+i
     b.h+i: b.h c.h+i
             touch b.h+i
     c.h+i: c.h
             touch b.h+i

The general notion is that for each .h file, you say that the .o depends
on the corresponding .h+i file.  The timestamp on this file represents
the latest time of all the .h files reachable from the corresponding .h
file.  Now make will do the recursion effects for you, and you only have
to keep straight which files are locally included, not the transitive
closure. 

(The touch rules could be made general "suffix" rules, of course.)

BTW, you might think that touching foo.h+i files is as bad as touching
the .h files as far as archives and file motels and other UIDish tools
are concerned, but in this case the file is empty and we WANT it to
be treated as a new UIDed file as far as archives and such go.

Anyhow, wayne-bob says: checkitout.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw at rti.rti.org