🚀 go-pugleaf

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" <totally subjective term> 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.