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

[Bill Hoffman]

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.
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();
};


-Bill