[Insight-users] Announce: WrapITK 0.3.0 released

[Darren Weber]

2009/6/29 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>

>
> Le 29 juin 09 à 23:27, Darren Weber a écrit :
>
>
>>
>>
>> Can we integrate this with a build for ITK 3.14?
>>
>> The build hasn't been tested inside itk. Quite often, when it's not
>> tested, it's broken.
>>
>>
>>  Should this replace the WrapITK that is packaged in ITK 3.14?
>>
>> No, but it may be a separate package. Would it be possible?
>>
>>
>> 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.
>>
>
> You can build wrapitk with an installed ITK - no need to keep the ITK
> source tree.



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.



>
>   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.
>>
>
> 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.
>

Oh.  I don't understand the wrapping process.



> 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:
>>
>> <itksrc>/Wrapping/WrapITK
>>
>
>
> I have a separate dir for wrapitk.
>
>
>> In the port, there is a separate download for CableSwig, which is unpacked
>> into:
>>
>> <itksrc>/Utilities/CableSwig
>>
>
> 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.
>

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?



> 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
>>
>> <itksrc>/Wrapping/WrapITK
>>
>> However, it may not be so simple.
>>
>
>
> I'm quite sure it won't work.
>


Right, cross out that option.


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...
>

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.


> Can't you simply make the wrapitk package depend on the ITK package,
> including for the build?
>

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).


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.
>

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

/opt/local/lib/python2.5/site-packages/WrapITK-3.14.pth
/opt/local/lib/python2.5/site-packages/WrapITK.pth -> WrapITK-3.14.pth

The WrapITK-3.14.pth file is modified to point to a version specific install
path:
# Python pth file to add WrapITK's path to sys.path.
/opt/local/lib/InsightToolkit-3.14/WrapITK/Python

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!

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.

Take care,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090630/e684bd8f/attachment.htm>