From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: 'make' woes (won't catch secondary dependancy)
Date: 8 Oct 92 01:07:35 GMT
Organization: negligable

In article <61255@aurs01.UUCP> throop@aurs01.UUCP (Wayne Throop) writes:
>>> h1.h: h2.h
>>>        touch h1.h
>>>
>>> That ought to work
>>  It'll work, but IMHO, it can be a pain in the @$$ 
>
>First of all, to say that a .h file depends on another .h file
>just because it includes it is incorrect.  There is nothing about
>the including .h file that actually changes on account of
>the included file changing.  Remember "x depends on y" means
>"some process needs to read y and (potentially) update x".
>
>With that agreed (I hope):

Unfortunately I don't agree.  There are two ways to interpret
the "depends" relationship.  The first, yours, means "file Y is
created by some process operating on file X", this is a very
specific, mechanistic interpretation.

I prefer "the meaning of the contents of file Y depends upon 
the (meaning of) the contents of file X"  This relies upon no
external process, and accurately states the relationship of
"depends on" as we use it, especially when it comes to include
files that include other include files.  (Perhaps this practice
was not as common when "make" was developed.....)

Of course, once the meaning of "Y" has changed, any file "Z" that
includes it also has had it's meaning changed.  Whether any process
must be invoked when the meaning of a file has changed is a separate
issue.

Y.h : X.h

Z : Z.c Y.h
	cc Z.c -o Z

With that out said, my original comment stands:

>>  IMHO, this is a bug in the specification of "make" that you need to
>>  update the target file in order to propigate changes down the dependency
>>  list.  There should really be a way to propigate changes based soley on
>>  the files the target is dependant on.

Your reply would, of course, be appropriate if I had agreed with
your premise.....

>No, make acts appropriately.  

(given your premise)

>A rule can decide not to update an output

Therein lies the difference, whether we are dealing with
a syntatic relationship, input files and output files and 
the process between, or a semantic relationship regarding 
the meaning of the contents of the files.
    ^^^^^^^

The "meaning" of an include file can be changed if the meaning
of a file that IT includes is changed, even if it, itself, has
not changed.  A file that depends on it, however, is in need of
being recompiled.  Make does not reflect this.

>if it isn't necessary, and the subsequent rules would quite properly
>not fire.  

proper for whom?  there is still a file in need of recompilation
that hasn't been processed because of the mechanistic "the date
on the file immediately prior to yours hasn't changed so I won't
do anything to you, nyah!" attitude of "make".  The "touch the
dependant .h file" method I recommended is required solely because
make is being driven syntacticly instead of semantically w/ regards
to what "depends upon" means.

>For example, suppose you edited a comment in a .c, or made a
>change that the optimizer produced identical code for.  Suppose further
>that your compiler noticed that the .o was the same.  Then, it could
>legitimately leave the old timestamp on the old .o, and avoid having to
>do a link.  

yup.  but that is a semantic (meaning) interpretation.  this would
be *great*.  but unfortunately my make is again mechanistic, so even
if I change a comment the darned thing gets recompiled (unavoidable
as far as I can tell) AND relinked (which would have been avoidable
if we were smart enough to check the results against the older
results as you described....)

>If dates were checked recursively this would not be
>possible.  

Would not?  IS not.  It isn't doing this NOW!  And say I change
a comment in a .h file 3 depends back, ok -- we recompile & get
a new .o, but we can still avoid the relink w/ your suggested
enhancement.  Let's find a make that handles BOTH of our suggestions!

>I think the real problem is that make does not allow for what I tend to
>call "virtual objects" or "conceptual objects".  Make treats only files
>in the file system.  

This is pretty much what I said earlier (and have elaborated upon with this
message).  A problem in the specification of "make".  


[ ... workaround deleted ... actually rather nice as workarounds
  go, much better than using touch on the dependant .h file directly ... ]

The question still remains, wouldn't it be nice to have a make
that worked correctly?  Again pointing to a problem in the specification
that the original make was written to.  Perhaps the only problem was
lack of forethought, and we all know about 20/20 hindsight....  That
doesn't mean we have to stick to it forever and ever amen.  Your
workaround shouldn't be required.  (But thanks for posting it!)


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Who knows what evil lurks in the hearts of men?"

Xref: sparky comp.lang.c:14765 comp.software-eng:3687 comp.sys.mac.programmer:16742