[ET Trac] [Einstein Toolkit] #1522: Improve determining make dependencies
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Tue Jan 21 10:24:18 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 eschnett):
Let's state the problem again. Assume we have a source tree consisting of
two files, "header.h" and "source.c", and where source.c includes
header.h. We build, everything is working fine, and the automatic
dependency tracking records that source.c depends on header.h
We then change the code, removing the file header.h, and chancing source.c
so that it doesn't include header.h any more. This is still self-
consistent, and if we say "make cleandeps", it will compile fine.
However, without the cleandeps, the Cactus make system remembers that
source.c depends on header.h. Since header.h does not exist any more, and
since there is no rule for generating it automatically, make will abort
with an error message. Yes, it will detect that source.c has changed and
needs to be rebuilt, but it currently doesn't know that this also means
that the dependencies are outdated and should be ignored.
The proposed change tells make in this case that it should not worry about
the missing file header.h. Thus make continues, decides that source.c
needs to be rebuilt since it changed, and will also generate new, correct
dependencies. All is fine.
I did not understand Roland's text about "useA" and "change in a file", or
why this would "circumvent make".
We can also examine how the proposed new system behaves in the presence of
errors. Assume that header.h has been deleted, and source.c has not been
modified. Make will then treat header.h as changed (since it is not
present), and rebuild source.c, leading to a compiler error pointing to
the problem. This is also good.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1522#comment:13>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list