[Insight-developers] Re: Integrating WrapITK into ITK CVS

[Gaetan Lehmann]

On Thu, 02 Nov 2006 16:11:58 +0100, Bill Hoffman  
<bill.hoffman at kitware.com> wrote:

> Gaetan Lehmann wrote:
>> On Tue, 29 Aug 2006 00:01:12 +0200, Bill Hoffman
>> <bill.hoffman at kitware.com> wrote:
>>
>>> OK, so it sounds like the next step would be to investigate the  
>>> generation
>>> of swig .i files from gccxml.  I agree it would solve a bunch of  
>>> problems
>>> if it can be made to work.    It would be better to get this working,
>>> than to do another swig update in CableSwig.  Now, we just need the  
>>> time
>>> to do it....
>>>
>>> As far as the investigation goes, I would say hand wrapping a few
>>> classes in itk that cross wrapper library boundaries would be the
>>> first step.   Any takers?
>>>
>>
>> yes, I've done it, and it seem to work :-))
>>
>> I have used (the very good) pygccxml to parse the output of gccxml for  
>> the
>> wrap_itkImage.cxx file, and generated an output which compile and run
>> without problem.
>> The generator program is attached.
>>
>> The program takes 2 arguments:
>>
>>    igenerator.py wrap_XXX.xml wrap_XXX.cxx
>>
>> wrap_XXX.cxx is required to be included in the generated c++ file
>> It currently display the result on the standard output - that's only a
>> test program which should be recoded in c.
>>
>> The next step is to define how to organize things in a consistent way,  
>> so
>> it can scale with the whole wrapping process. For example, a wrapper  
>> must
>> know that a superclass is wrapped in another file. Any Idea ?
>>
>> Regards,
>>
>> Gaetan
> Another issue is this:
>  ::itk::ImageRegion<2> const & GetBufferedRegion() const;
>
> That is going to have to use the typedef name for ImageRegion and not  
> the template name.

The problem here is that the ImageRegion wrapper will be defined in  
another file. If we define it in the same file, the full c++ name is  
replaced by the wrapped name, and there is no problem anymore.

> Also, you really have not done it....   We need a few classes that cross  
> a library boundary
> that work with .i files.
>
> Basically, for each class that is referenced in a class that is being  
> wrapped you need to know:
> (by referenced, I mean return value, function argument, or parent class)
>
> -  is this class wrapped
> -  if it is wrapped, what is its typedef name
> -  if it is wrapped what is the name of the module that it is wrapped in.
>
> The .i files will have to do the correct swig import , include stuff to  
> get all of this to work.
> Currently, the .idx files do this step.   I do not think there is a way  
> around the .idx files,
> but maybe there is.   Somehow we have to answer the above questions.   
> Also, a small example
> done by hand that does something like this would be a good starting  
> place:
>
> class A  -- in module A
> class B -- in module B    //
> class C -- in module C
>
>
> class A
> {
> public:
> virtual A* foo();
> };
>
> class B : public A
> {
> public:
> virtual A* foo();
> };
>
> class C : public B
> {
> virtual A* foo();
> };
>

Yes that's what I mean by "The next step is to define how to organize  
things in a consistent way, so it can scale with the whole wrapping  
process" - I must say your explanation is much clear :-)

The small program I wrote is only there to show that it can work - that's  
the "next step" you have defined last august. There is still many problems  
to solve, and surely most of the solutions to those problems are already  
there in the current wrapping system.

Someone want to take the next step ?

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