[Insight-users] Announce: WrapITK 0.3.0 released

[Gaëtan Lehmann]

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.

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

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

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

>
> I conclude that we do have two options:
>
> a) A separate port for WrapITK (oh god, please no!)
> b) Wait for updates of WrapITK in the ITK release program (probably  
> the way to go)
>
> 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.

No, that's not necessary, and is likely to NOT work.

>   In any case, the WrapITK port must contain all the ITK src code  
> somehow

No: it can take everything it needs from the installed ITK.

> 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's not an option with WrapITK - it requires shared libs,  
> right?).

Right.

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

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

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.

Gaëtan


-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090630/32fac471/attachment.pgp>