tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: make: ignore stale .depend

>Well, I am trying to understand what's going on here and how things are
>supposed to work. I run make build, and after rb.h was renamed to rbtree.h
>I get warnings about rb.h not found in /usr/src/lib/librump. Each time
>I type make dependall in that directory, the dependencies are not being

This is a problem with;
.depend exists, and appears to be newer than ${__DPSRCS.d}, 
so 'make depend' or 'make dependall' will not update it.
Similarly, the .d.c suffix rule won't help since the .c file hasn't changed.

By itself, my patch won't help that - or equivalent is what
you need for that, ie, the .d files are produced as a consequence of
compiling the .o rather than as a separate step.  I've been using this
model successfully for 10 years or so.

Also, the case that my patch (even with is particularly
useful for is reachover builds.  For .h's the worst case is that files
get needlessly recompiled.  However (as the test case I quoted shows),
if a .c file which is being compiled via reachover is moved, the build
fails, and cannot proceed unless you remove the .depend file.

With is patch, a moved .c file is no more hassle than a moved .h,
and with (or equivalent), .depend gets updated and you never
have to worry about it again. can't help if the compile

>I understand, but I want to find a solution that does not cause make to
>look for things in unexpected places.

Agreed.  For .c files (or more generally files which are sources)
I don't think this will.  Consider the case where where a makefile does
a reachover build and the dist directory changes.  The makefile will
have been edited to have a new .PATH: to find the new srcs, so 
it "just works".

The only case I can see getting screwed, is when a .h (more generally
something which is not fed to a compiler directly) is moved. For this
case, is all you really need, and searching for the file via
.PATH could possibly find a file which is not the right one, so make
could reach a bad decision - thinking target is up-to-date.

This case is dealt with automatically by meta mode, because regardless
of what the mtimes say, meta_oodate() will note that a file that was
used no longer exists and immediate flag out-of-date.

That notion - considering the target out-of-date immediately if there
are stale .depend entries could easily be added to non-meta mode, and
would solve the above.

Note that even without that, if the .h changed name, the .c file should
have been changed, and would need recompiling anyway and will
ensure the right things happen next time.

I'll have a dig to see if there is any clue in the GNode, by the time
Dir_MTime() is called which could avoid identify the .h vs .c case
(the later being the only one that really matters - s/.[ch]/language of choice/)

Bottom line though, this patch is mainly useful if you are already
solving the case you mention - eg. via
Note: that meta mode does this even better, the next rev of my mk-files
tgz should include the basic bits needed.


Home | Main Index | Thread Index | Old Index