[Insight-developers] using swig to wrap ITK - a summary of the tcon (and a little much)

[Bill Hoffman]

Gaëtan Lehmann wrote:
>
> Hi,
>
> Because I'm not sure how much clear I have been during the tcon, here 
> is in short what have been said, and also some things I have forgotten:
>
> The current wrapping system:
>  - work on linux and windows with tcl, python and java
>  - known to have problems on mac os (java, python) and solaris (java)
>  - the problems detailed in the WrapITK article, including the small 
> coverage, and inconsistency in wrapped types
>
> WrapITK:
>  - 66% of the filters wrapped
>  - tcl, python, java
>  - python typemaps, to be able to use python types rather than simple 
> itk objects,
>    like FixedArray, Index, Size, ...
>  - no typemaps for tcl and java
>  - lacks some custom classes from the previous wrapping system in java 
> and tcl
>  - tested on linux, mac os, and recently, solaris
>  - still lots of problems with windows (especially with java), even if 
> some users have reported using it on that plateform (msvc 7.1 only I 
> think)
>
> What will be better with swig:
>  - a lot easier to customize
>  - build with python 2.5
>  - should help to fix problems with very long file names
>  - may help to fix build caused by too big generated c++ files
>  - no need to maintain a branch of swig
>
> WrapITK with swig status:
>  - swig is still not able to read ITK headers - they still need to be 
> read by gccxml. The output of gccxml is converted to a swig interface 
> with igenerator.py
>  - python only
>  - made on mac os
>  - all currently wrapped itk classes builds with swig
>  - no customization from the current wrapitk, like typemaps
>  - but some other customizations, like vector support
>  - no cmake configurations support
>  - based on cableidx and pygccxml, so need python to build
>  - problems with cmake dependencies
>  - don't group the groups in a few shared modules
>  - no template with dict interface
>  - require pygccxml cvs and swig cvs because some bugs have been fixed 
> while working on wrapping ITK with swig
>  - only a few changes have been made (to respect the wrapping order 
> imposed by swig) in the WrapITK/Modules directory
>  - roughly, igenerator.py have took about 2 days of work, modifying 
> WrapITK have took 1 day. The bugs above, and a misunderstanding of 
> pygccxml query interface took me one more day
>
> What need to be done (* mark for what I need help), in the order I 
> think it should be done:
>  - fix the cmake dependencies *
>  - add the customizations
>    - basic types like std::string, std::exception, ...
>    - typemaps currently in WrapITK
>    - PyCommand, PyImageToImageFilter
>  - fix the dict interface for the templates
> (at that point, the current python tests should all pass on unix-like 
> systems)
>  - support cmake configurations
>  - make it work on all the systems, and submit daily tests for all 
> those systems on the dashboard *
>  - add support for java (*?)
>  - add support for tcl and the customizations from the current wrapper 
> (TkImageViewer2D, TclCommand, ...) *
>  - more python customizations: __getitem__(), __len__(), __str__(), 
> ... like in the current optional patch
>  - recode igenerator.py in c++ to no more use pygccxml (igenerator.py 
> is attached for the ones who want to have an idea of the work to do) *
> (the following items are too be done later)
>  - better filter coverage *
>  - support more languages
>  - ...
>
> What still remain to decide:
>  - when switch to swig (I think it's clear that the switch is a good 
> thing)
>  - who can/want to work on the the items marked with a "*" in the 
> "What need to be done" section above (any help is welcome for the 
> other items too :-)
>  - how to proceed:
>    - fix WrapITK with cableswig on windows, or switch first to swig, 
> and make sure it builds on windows after that
>    - create a new cvs branch or a new cvs check out
>
> Gaetan
>
I think that generation of swig .i files is the right way to go.   Using 
the cable part of CableSwig it should be easy to do.
Cable is basically a c++ class description library that can be populated 
by reading the xml output by gccxml.

That said, before moving forward, I think that a key proof of concept 
demo needs to be done with swig.i files.
By hand or generated, we need to see working swig .i files that wrap  
several classes that inherit from each
other but are in different libraries.  We need to see how the import and 
module stuff will be handled in the swig
.i files.   The demo should be something like this:

module A  (classes A B wrapped)
module B ( classes C  D wrapped)
module C (classes E F wrapped)

With inheritance going across the module boundaries and member functions 
that reference classes
that go across the module boundaries.   (by modules I mean shared 
libraries .so or .dll on windows.)
Then the example should be done in all the target languages (java, tcl, 
python) on all the target platforms
(windows, linux, osx).  This should not be a complicated thing to do for 
a swig expert.   (I am BTW, not
a swig expert).   Once this proof of concept is working, then we can 
worry about auto-generating it with
gccxml.  Before this has been done, and we know it works, it is not 
worth discussing this as an option
IMO.  

CableSwig does some tricks on the internals of swig as it runs right now 
making all of this work.
I do not know how to do those same things in a swig .i file.  I suspect 
that it will work, but until
I see it, I would not be willing to make any commitments to this effort.

-Bill