[ET Trac] [Einstein Toolkit] #1522: Improve determining make dependencies

Einstein Toolkit trac-noreply at einsteintoolkit.org
Tue Jan 21 15:57:53 CST 2014

#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"
 #  include "b.h"
 ... 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.

Ticket URL: <https://trac.einsteintoolkit.org/ticket/1522#comment:14>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit

More information about the Trac mailing list