<html>#41: When an external library is rebuilt, its dependencies should also be rebuilt
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Erik Schnetter</td></tr>
<tr><td style='text-align:right'> Status:</td><td>open</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>bug</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><table>
<tr><td>status:</td><td>open (was new)</td></tr>
</table></p>
<p>When an external library (such as e.g. BLAS) is rebuilt, then all its dependencies (such as e.g. LAPACK) should also be rebuilt. Cactus knows these dependencies via the configuration.ccl declarations, but these are not checked in the scripts that determine whether to rebuild.</p>
<p><strong>Keyword:</strong></p>
<p>Comment (by Roland Haas):</p>
<p>There are three cases of dependencies:</p>
<ol>
<li>the library file itself, which does not require recompilation of the client since the linker will take care of using the new library automatically</li>
<li>any header files generated, these are already tracked in the <code>.d</code> files created by the various <code>XXX_DEPEND</code> tools in <code>lib/make/make.config.rules.in</code></li>
<li>Fortran module files <code>.mod</code>. These are not currently tracked by anything since the <code>F_DEPEND_MODULES</code> functionality is limited to modules in the same thorn and sets up a dependency assuming that a module <code>foo</code> is provided by a source file <code>foo.F90</code> which is not sufficient.</li>
</ol>
<p>For this last case one can however make use of the fact that gfortran accepts the same <code>-M -MF</code> options that gcc (or cpp) do to write out dependency files. These do track modules wherever they are but assume that the module must exist when gfortran is first called. For ExternalLibraries this will be the case since Cactus already ensures that thorns REQUIREing each other are build in the correct order (exactly for the reason to provide <code>.mod</code> files).</p>
<p>An example usage looks like this:</p>
<div class="codehilite language-Shell"><pre><span></span>mkdir bing
cat <span class="s"><<EOF >bing/foo.F90</span>
<span class="s">#include "bar.h"</span>
<span class="s">subroutine foo</span>
<span class="s"> use bar</span>
<span class="s"> implicit none</span>
<span class="s">end subroutine</span>
<span class="s">EOF</span>
cat >bar.F90 <span class="s"><<EOF</span>
<span class="s">module bar</span>
<span class="s">end module</span>
<span class="s">EOF</span>
gfortran -c bar.F90
gfortran -J<span class="nv">$PWD</span>/.. -M -MF foo.F90.d foo.F90
</pre></div>
<p>Thus the best way to achieve the goal in this ticket seems to be to extend <code>F_DEPEND</code> or <code>F_DEPEND_MODULES</code> to call <code>F90</code> as well as <code>FPP</code> (since
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/41/when-an-external-library-is-rebuilt-its'>https://bitbucket.org/einsteintoolkit/tickets/issues/41/when-an-external-library-is-rebuilt-its</a></p>
</html>