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