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

[Gaetan Lehmann]

Here is a new version able to read the .idx files.

Do you know how to build all the generated c++ files in a single shared  
object, as is it currently done ?


On Thu, 02 Nov 2006 16:37:43 +0100, Gaetan Lehmann  
<gaetan.lehmann at jouy.inra.fr> wrote:

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: igenerator.py
Type: application/octet-stream
Size: 6748 bytes
Desc: not available
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20061102/e4c6939d/igenerator.obj