#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.