<html>#2834: Baikal regeneration instruction in README fail
<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>ET_2024_11</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>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td></td></tr>
</table>
<p>Comment (by Roland Haas):</p>
<p>These changes are all fine and there is nothing wrong with the generated Baikal* code updating during the release lifetime. What I am after is to have a way for the release manager and potential Baikal* users to generate the C code from the original Python code. So that in case one has bug fixes to propose one can actually start from the real source code and not something unknown. </p>
<p>Having the full thorn be generated with just a single command is very useful for the release manager since they have to generate very many thorns and if each one required a dozen manual steps (worst would be “edit this file …”), then this becomes very time consuming. </p>
<p>The Kranc generated files uniformly require that one does <code>make</code> in the the <code>m</code> directory which contains the actual source code. RIght now with Baikal it seems that the source used is in <code>nrpy</code> and stored in some, to most users, unknown directory in <code>~/.local</code> unless one uses a virtualenv.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme'>https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regeneration-instruction-in-readme</a></p>
</html>