Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!uhccux!munnari.oz.au!goanna!minyos!s887212
From: s887212@minyos.xx.rmit.oz.au (Stephen Riehm [Romulis])
Newsgroups: comp.unix.programmer
Subject: Re: Makefiles -- .c and .h
Message-ID: <6268@minyos.xx.rmit.oz.au>
Date: 16 Nov 90 00:54:30 GMT
References: <9011151442.AA02010@decpa.pa.dec.com> <1990Nov15.172323.23431@athena.mit.edu>
Organization: RMIT Computer Centre, Melbourne Australia.
Lines: 37

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).

[stuff not saved]

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

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.

Comments welcome by email or news.

thanx in advance
============================================================================
Romulis [Stephen Riehm]	            Royal Melbourne Institute of Technology,
					       (124 Latrobe St., Melbourne.)
s887212@minyos.xx.rmit.oz.au					   Australia.

@>---`--,--( Still Stuck on the wrong side of the deep pink sea )--.--'---<@
======================< Insert Usual Disclaimer >===========================