[ITK-users] Using swig on external standalone libraries that use ITK

[Matt McCormick]

Hello Nathan,

> It's been a while!

Welcome back :-)


> Thanks for the prompt response. WrapITK is a pretty neat
> feature and I'm glad to see recent work to better document it. Currently I
> use the C++ documentation to get an idea how to use the Python version of
> the functionality. I like your suggested workarounds and I'll look into
> that.
>
> The Wrapping folder generated by WrapITK seems to have a lot of
> module/interface information about the WrapITK. Wouldn't it be possible to
> have something like numpy.i for ITK? Then you could do something as
> prescribed by Swig's documentation:
>
> %import(module="itk") "itk.i"
>
> And this supposedly helps Swig with tricky multi-module setups. I realize
> itk.i doesn't actually do anything currently except ignore some allocators
> in LightObject (I think). Some of these .i/.h files would have to be
> properly installed in share/include folders. Well, it doesn't resolve the
> issue where WrapITK generates brand new classes for some of the ITK data
> types.

I don't think the current infrastructure is intended to be used in
this way, but improvements here would be welcome.


> Out of curiosity, what is the rationale for generating brand new classes
> for, say, itk::Image or itk::Image::Pointer anyway?

Part of the consideration here is that ITK uses itk::LightObject,
itk::SmartPointer for memory management.


Thanks,
Matt