Re: was: RE: auto-dep cannot possibly work?

[David Boyce]

On Fri, Dec 11, 2009 at 4:22 PM, Mark Galeck (CW) <address@hidden> wrote:
> Hello,  this is about a thread that was here a while ago, where I argued that 
> some "bizarre" cases should be taken care of by auto-dependency generation.
>
> I want to say, that after chasing this wild goose for a while, I came to 
> understand that it is not feasible in principle to cover the case of new 
> header files appearing, without changing existing sources.
>
> What is more, I finally came to understand that Paul was right, of course, 
> that it is up to the developer to edit the makefile, do "make clean" or 
> whatever needs to be done, if they introduce new files without touching 
> existing sources.  Make should not be expected to take care of that.

> Thank you Paul, it is a pleasure to learn from you, even though I am a little 
> slow with it, please excuse that.

A classy touch.

You know, there was something I was going to say back when this thread
was active but everyone seemed a little touchy and I didn't want to
make it worse ... but now that's over and we're all friends I think I
will.

I wish both you and Paul would 'come to understand' that I was right
way back in the early part of the thread, that it is absolutely
"feasible in principle to cover the case of new header files appearing
..." by using the directories themselves as prerequisites. By this I
mean that it's an objectively correct solution. The objection raised,
as I recall, was that people may make any kind of unrelated changes in
include dirs (temp files, backup files) which will trigger
"unnecessary" builds. To which I would say then don't do that - you
must design your structure and process such that you're not searching
directories in which people work all the time. This is not so hard -
for instance you can make a "./include" directory and populate it with
symlinks to the header files where they actually live.  Since this dir
exists only to be searched at build time, and nothing really lives
there, it won't get visited much.

A related objection was that even if the change really does reflect a
new header file, it probably won't eclipse an existing one and/or
won't change the resulting binaries. This again is true but the same
can be said about files too. In fact, if you think it out carefully
the analogy between these directories and plain files is almost
perfect. When I modify an existing header file, more often than not
I'm simply adding a new macro or declaration to it. Or I might be
adding comments or updating the copyright to 2010 (reminder to all).
In all these cases make takes an appropriately pessimistic approach -
since it has no way to know the semantic content of the change, it
rebuilds everything that could possibly be affected. And if someone
complained about the changes causing "unneeded" rebuilds, you'd say
either don't make the changes or get used to the rebuilds. When you
use dependencies on directories in search paths make behaves in
precisely the same way - in both cases, in some sense you're getting
unnecessary rebuilds but it's the optimal set given what we know a
priori.

Bottom line, there is a solution to this problem which is both elegant
and 100% correct. It just may not be the answer you want it to be.
Anyway, that's my contention and I'd be interested (and surprised) to
be shown wrong now that the other shouting has died down.

BTW, I don't remember if it came up before but it sounds like ccache
ought to be mentioned in this thread because it can make
determinations based on semantic content and thus partners well with
make. You might want to look into it if you haven't before.

David Boyce