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

[Gaëtan Lehmann]

Le Mon, 20 Nov 2006 14:51:15 +0100, Bill Hoffman  
<bill.hoffman at kitware.com> a écrit:

> Gaëtan Lehmann wrote:
>>
>> and - please - no more tell me what I'm doing is not constructive
>>
>> BTW, I'm not making attacks against CVS. CVS is a good tool, but there  
>> are some very better versioning systems. I'll not describe why - it's  
>> very easy to find with google
> Yes, and we are all aware of CVS's short falls, but it has nothing to do  
> with wrapping and ITK.
> So, lets keep this on topic.   The topic at hand is improving the  
> wrapping process.   And, yes,
> you have done great things towards that goal.   I would like to see you  
> make it across the finish
> line and get this working in ITK on all the platforms and languages that  
> the old wrappers worked
> with.

I will not learn a new development environment in the near future, so I  
will not do that.

But I would be really pleased to help someone used to develop on windows  
to fix the problems with WrapITK.

> So, to answer your question one module per class would be too many .so  
> files.   If you look at VTK,
> there are 1000 classes.  That would be 1000 .so files or dlls, I am not  
> sure what problems that would cause but
> for one thing just looking at a directory with a 1000 files can be  
> slow.   Swig has the idea that whole
> libraries should NOT be wrapped.   The Swig way is to  create a smaller  
> API that is wrapped.  Perhaps a
> hand created API.   We want an entire class library wrapped.   This  
> changes the design requirements a bit.

Ok, so I will make it work with a few libs, as it is done currently in  
WrapITK.
It should also fix the template-parameters-as-dict-interface feature

>
> So, I  guess this means you are not interested in doing the smaller  
> example and feasibility study I am interested in.
> You seem to have not addressed that issue in this email.   Perhaps you  
> could use your pygccxml based system
> to create the .i files for the test to avoid doing much by hand.   The  
> .i files should not have much
> python specific stuff in them.

there is no python specific code in the .i files. The language specific  
code will be put in a wrap_XXX_ext.i file, and the file put in a python  
(or tcl or any other language) directory

>   I really don't see the point in moving forward until we are 100% sure  
> it is going
> to work.  ( I am right now about 95% sure....)   If you are interested,  
> I can create the library of sample classes
> to wrap.

I'm sending you the files off list

Gaetan



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