Actually, "config" changes are safe. That's because "make dep" doesn't even
bother looking at the config options: it creates a dependency tree that is
independent of which files you'll actually compile, because it just goes
through the .c/.h files with brute force and ignores any #ifdef's it
encounters.
However, there _is_ one configuration change that you need to look up with,,
and that's changing the architecture. Of course, if you edit the main
makefile and change the architecture you should have a clean source tree
anyway, so this is usually not a problem.
> 2) Applying a patch that :-
> 3) Renaming or copying the linux source directory!
> 4) Anything else?
Applying a patch is "pseudo-safe": the act of patching will update the times
of any files it changes, so if the dependencies changed the files will get
recompiled anyway. But yes, the dependencies will then be out of sync, and
any _further_ changes may end up not being noticed, and you're eventually
better off doing "make dep" again.
In short, the dependencies are definitely not 100% reliable. "make dep"
isn't even close to perfect, but it's as good as it gets without being
excessively clever. It works most of the time, but I'd agree that it's
generally a good idea to re-run "make dep" after any larger changes.
The dependencies are most useful to kernel hackers that tend to make
incremental small changes and know what those changes are and wanting to
recompile the kernel quickly without having to worry about which parts to
recompile.
In short, "make dep" is most useful for _me_ ;-)
Linus