<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Can we integrate this with a build for ITK 3.14?<br>
</blockquote>
<br></div>
The build hasn&#39;t been tested inside itk. Quite often, when it&#39;s not tested, it&#39;s broken.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
  Should this replace the WrapITK that is packaged in ITK 3.14?<br>
</blockquote>
<br></div>
No, but it may be a separate package. Would it be possible?</blockquote><div><br><br>Yes, almost anything is possible.  However, it&#39;s a total pain in the neck for porting with ITK.  The reason is simple, I think you need the entire source tree for ITK in order to build WrapITK.  In this case, it doesn&#39;t make any sense to have a separate port for WrapITK.  On the other hand, if WrapITK were simply to link against compiled ITK libraries, then a separate port would be easy.  Given the nature of WrapITK, that&#39;s not an option.<br>
</div></div><br>Maybe you can enlighten me on how you develop WrapITK without having WrapITK within the ITK src tree.  As I see it in ITK 3.14.0, we have:<br><br>&lt;itksrc&gt;/Wrapping/WrapITK<br><br>In the port, there is a separate download for CableSwig, which is unpacked into:<br>
<br>&lt;itksrc&gt;/Utilities/CableSwig<br><br>If we could be confident that a separate release package could be downloaded for WrapITK, it would be easy to unpack and replace the content in<br><br>&lt;itksrc&gt;/Wrapping/WrapITK<br>

<br>However, it may not be so simple.<br><br>I conclude that we do have two options:<br><br>a) A separate port for WrapITK (oh god, please no!)<br>b) Wait for updates of WrapITK in the ITK release program (probably the way to go)<br>
<br>If we did create a port for option a, then I assume that it must be an almost direct replica of the current port for InsightToolkit, but it must somehow replace the WrapITK components.  In any case, the WrapITK port must contain all the ITK src code somehow and it would need a full installation of ITK for all the shared library links to work (unless the whole thing were built static, but I think that&#39;s not an option with WrapITK - it requires shared libs, right?).<br>
<br>Best,<br>Darren<br><br>