<html>#2237: build system has trouble handling files that are removed from Makefile
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Roland Haas</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Cactus</td></tr>
</table>
<p>Changes (by Roland Haas):</p>
<p>Currently if a source file (C and C++ mostly) that used to be listed in SRCS but is now no longer listed because it is <code>#included</code> in another source file, then Cactus does not remove the preprocessed copy of the file in <code>configs/sim/build/THORNNAME</code> which leads the compiler to <code>#include</code> that file rather than the one in the thorn's src directory. Since the file is no longer listed in SRCS it is also never preprocessed again, leaving the stale file around in <code>configs/sim/build/THORNNAME</code> forever.</p>
<p>A <code>make sim-clean</code> fixes this at the cost of a full recompile, however such a clean does not happen (automatically) on the Jenkins build system when it does an incremental build and even on a workstation one has to be aware that (and how) Cactus preprocesses source files.</p>
<p>A similar issue (I assume) exists if one removes a source file completely from the makefile.</p>
<p>A possible fix would be to look at the object list for the thorn, then remove any objects not in the objectlist and their corresponding preprocessed source file (which has the same name but with <code>.o</code> removed, ie is called <code>foo.c.o</code> and not <code>foo.o</code>). </p>
<p>This is still not perfect since it will not handle the case of Fortran and removing F90 file that provided a module file since the <code>foo.mod</code> file is in configs/scratch and its name is not derivable from an object file name (at least not consistently, even though Cactus does encourage files that provide module <code>foo</code> to be named <code>foo.F90</code> so that it can set up dependency tracking for the <em>client</em> files of the module, ie those that <code>use</code> it).</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2237/build-system-has-trouble-handling-files'>https://bitbucket.org/einsteintoolkit/tickets/issues/2237/build-system-has-trouble-handling-files</a></p>
</html>