[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