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

Einstein Toolkit trac-noreply at einsteintoolkit.org
Mon Jan 20 12:58:09 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):

 Replying to comment:3. I do not know on right now what the usual situation
 is that makes me have to recompile from scratch because of the dependency
 trackin,g so do not know if it falls under this point. I'll wait until it
 happens again and try and verify.

 For the example: Rather than recompiling when when the dependency file is
 missing I'd rather say that this example circumvents make's dependency
 tracking systems since the is a case where the file needs to be recompiled
 (when useA changes) that cannot be tracked by make's dependency tracking
 system. So rather one would have to change useA in a file and then add
 this file to the list of dependencies. This is pretty much the situation
 we currently have with all the external libraries and their FOO_DIR
 variables that are set in the Makefile but there is no way of tracking
 their change (unless we implement #1264 and #1017) so that changing them
 then either requires some (private) knowledge of the build system to touch
 just the right files to trigger recompilation or (shudder) a -realclan and
 full rebuild.

 We currently do not include the Makefile (or at least not the option list
 in either config-info or config-data/make.configuration.defn) in the list
 of dependencies. While including them might strictly be the correct thing,
 I would rather not do so since it would trigger a full recompile. Changing
 those files often happens when one wants to add an extra define or change
 and optimization setting or change a library path when debugging. Having
 this trigger a full recompile would be quite disruptive to this process. I
 think that having to do a make sim-clean after such a change is acceptable
 in this case.

 Basically, I am saying that have a few (well documented) cases where it
 fails (but a system that is fast and useful in the more common cases) is
 preferable to having a system that always works but is always very slow.

 Given that sed syntax is occasionally a bit hard to read and that the "$"
 duplication required in Makefiles does not make it better, possibly a set
 of comments along the lines
 # postprocess dependency files into a format acceptable to make
 # 1. adjust final target name due to mv at end of recipe
 # 2. remove comments (everything after a '#')
 # 3. remove the target
 # 3. remove line continuation characters (\)
 # 4. delete empty lines
 # 5. add a ":" to the end of the line
 which is a pretty much the set of comments that is in SpEC for the
 (almost) same set of sed commands.

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

More information about the Trac mailing list