<br><br><div class="gmail_quote">2009/6/29 Gaëtan Lehmann <span dir="ltr"><<a href="mailto:gaetan.lehmann@jouy.inra.fr">gaetan.lehmann@jouy.inra.fr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Le 29 juin 09 à 23:27, Darren Weber a écrit :<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>
<br>
<br>
Can we integrate this with a build for ITK 3.14?<br>
<br>
The build hasn't been tested inside itk. Quite often, when it's not tested, it's broken.<br>
<br>
<br>
Should this replace the WrapITK that is packaged in ITK 3.14?<br>
<br>
No, but it may be a separate package. Would it be possible?<br>
<br>
<br>
Yes, almost anything is possible. However, it'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.<br>
</blockquote>
<br></div>
You can build wrapitk with an installed ITK - no need to keep the ITK source tree.</blockquote><div><br><br>Alright, then we can have a separate port for WrapITK. In that case, I suppose we should disable the wrap support in the InsightToolkit, or we should provide for multiple installation paths that don't conflict. I've done a little of that work already to provide version specific ports for ITK @ 3.12 and 3.14.<br>
<br> </div><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>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In this case, it doesn'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's not an option.<br>
</blockquote>
<br></div>
It's linked with ITK, and it uses the headers from itk during the build, nothing more. Just as any normal application using a normal library.<div class="im"></div></blockquote><div><br>Oh. I don't understand the wrapping process.<br>
<br> </div><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"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>
<itksrc>/Wrapping/WrapITK<br>
</blockquote><br>
<br></div>
I have a separate dir for wrapitk.<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>
In the port, there is a separate download for CableSwig, which is unpacked into:<br>
<br>
<itksrc>/Utilities/CableSwig<br>
</blockquote>
<br></div>
I built it as a separate package. I think that would be a good thing to have it as a separate package in macport too.<div class="im"></div></blockquote><div><br>I have a separate MacPort for cableswig, based on a cvs checkout rather than a version specific release in sync with the ITK release versions. Maybe I should be using the version specific releases in sync with the ITK releases?<br>
<br> </div><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"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>
<itksrc>/Wrapping/WrapITK<br>
<br>
However, it may not be so simple.<br>
</blockquote><br>
<br></div>
I'm quite sure it won't work.<div class="im"></div></blockquote><div><br><br>Right, cross out that option.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Really, building wrapitk is not that difficult. It builds fine with the installed ITK, CableSwig, Python, Java, Tcl, doxygen and swig. And from my packaging experience (for mandriva), it's easier to package CableSwig, ITK and WrapITK in 3 different packages than into a single one, at least because it decreases the build time for a single packgage. Also, wrapitk 0.3 builds fine with "make -j16" - that's what I'm using on my new host. I think you're not doing parallel build at this time in your package...<br>
</blockquote><div><br>Right, I found some inconsistent failures on a dual intel quad-core system with parallel builds enabled. Sometimes it works, but sometimes it fails at irregular points in the build, so I decided to take the reliable road rather than the speedy road with sharp corners on the cliff.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Can't you simply make the wrapitk package depend on the ITK package, including for the build?<br>
</blockquote><div><br>Looks like this may be the way to go in order to be on the cutting edge for WrapITK (it should be fine so long as it's a cutting edge, not a bleeding edge).<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The only difficult part, I think, is how to make the packages so that both wrapitk versions can be there. Or, if that's not possible, how to define which one should be there.<br><font color="#888888">
</font></blockquote><div><br>I did a bit of work for this so that wrapping would work for simultaneous installs for ITK @ 3.12 and 3.14, but I've not actually tested how the python import process resolves things. That is, I think it is now possible to run `sudo port install InsightToolkit312 +wrap` and then also run `sudo port install InsightToolkit +wrap` without any overlap in the installation files. Nearly everything gets installed into version specific paths and file names, but some symlinks are created for the default paths, like /opt/local/lib/InsightToolkit is a symlink to /opt/local/lib/InsightToolkit-<version>. However, I'm not sure which of the python modules are loaded (likewise for java; the itkwish is a symlink to a version specific file called itkwish-3.14 or itkwish-3.12). For python WrapITK, we have<br>
<br>/opt/local/lib/python2.5/site-packages/WrapITK-3.14.pth<br>/opt/local/lib/python2.5/site-packages/WrapITK.pth -> WrapITK-3.14.pth<br><br>The WrapITK-3.14.pth file is modified to point to a version specific install path:<br>
# Python pth file to add WrapITK's path to sys.path.<br>/opt/local/lib/InsightToolkit-3.14/WrapITK/Python<br><br>It would be nice to have an InsightToolkitSelect port to manage a few symlinks to easily set a default installation version. I made a start on that, but there's never enough time in the day!<br>
<br></div></div>The addition of a separate WrapITK port may add more complexity to this install path issue. Do you have any wise suggestions on where to install a separate WrapITK port? It will probably not be installed anywhere below /opt/local/lib/InsightToolkit-<version> to avoid conflicts with the main ITK port.<br>
<br>Take care, <br>Darren<br><br>