Messages in this thread |  | | Date | Fri, 1 Nov 1996 03:52:57 +0200 (EET) | From | Linus Torvalds <> | Subject | Re: make dep gotchas |
| |
On Fri, 1 Nov 1996, Keith Owens wrote: > > Since make dep tracks the relationship of source to headers > (current_directory/.depend) and headers to headers (top_dir/.hdepend), > make dep must be run after *any* change that affects this relationship. > This includes :- > > 1) Configuration changes.
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
|  |