#1522: Improve determining make dependencies --------------------------+------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
comment:3 contains a sample code snippet which is used to explain why a file needs to be recompiled when its dependency information (.d file) is missing. This seems to have been in reply to me voicing a desire to be able to quickly regenerate dependency files without having to fully compile (and link etc) the cdoe. The example given is:
{{{ #if useA # include "a.h" #else # include "b.h" #endif ... code using stuff declared in a.h or b.h ... }}}
and the text in comment:3 continues "f there is a change that makes source.c switch from using a.h to using b.h, then it needs to be recompiled. However, both a.h and b.h may be older than the object file source.o -- so keeping source.o around is an error, as neither the old nor the new dependencies would indicate that source.o is out of date. Hence, re-generating dependencies without recompiling is an error.". I wanted to point out that the reason that the file needs recompilation is that "useA" was changed which is what makes is switch from using a.h to b.h. If useA is changed in a file on which the example file depends then make will pick up the change and will recompile the example file. If useA is changed eg via command line options then make will not pick up the change, the example file will not be compiled and there is a problem. I wanted to point out that the problem is that the example introduces a cause for the example file to require recompilation (switching from a.h to b.h due to a change in useA) that is not trackable by make. Making files recompile when the dependency information file (.d) is missing seems to be a workaround since it forces all files to be recompiled when one performs a -cleandeps. So I am not convinced by the example that (fully) recompiling a source file when the dependency (.d) file is missing is required, rather than first constructing a fresh .d file and then using the information in it to decide whether the source file needs recompilation. That is I would have expected the .d files to be just caches for deciding when to recompile but that they can at all times be regenerated from the source files. In that I may well be mistaken.