https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=GduI1t&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T07:03:49ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=Proposals:Refactoring_Wrapping&diff=8813Proposals:Refactoring Wrapping2007-04-18T10:41:40Z<p>GduI1t: </p>
<hr />
<div>= Refactoring ITK Wrapping =<br />
<br />
The current process used for Wrapping ITK requires a number of steps for adding new classes to be wrapped.<br />
Some of those steps can be simplified if the wrapping process is reorganized. <br />
<br />
This proposal gathers the work of <br />
<br />
* Benoit Regrain (Creatis Team, France) http://www.creatis.insa-lyon.fr/NEW/General/Presentation.php <br />
* Gaetan Lehmann (Inra, France) http://www.jouy.inra.fr/<br />
<br />
As a background, <br />
<br />
* Creatis already contributed to ITK the library GDCM that is currently the official DICOM reading and writing library. <br />
* Gaetan is the official packager ITK for Linux Mandrake.<br />
<br />
= Proposal =<br />
<br />
== Use of CMake to generate wrapping ==<br />
<br />
* All wrap_Xxx.cxx files, concerning the ITK classes wrapping, are now directly generated by CMake.<br />
* All wrap_XxxLang.cxx files, concerning the module wrapping, are now directly generated by CMake<br />
<br />
The advantages of these changes are:<br />
<br />
* There is no enough C macros (that are numerous and copied between some files... ex : All Transform classes wrapping).<br />
* All classes are wrapped with consistent rules. The mangled name is then coherent between all classes.<br />
* It simplifies the integration of the two next points (Wrap an own class and Tree of templated classes)<br />
* The itkCSwigMacro.h and itkCSwigImage.h files are now useless...<br />
* Best support for future ITK addons<br />
<br />
The disadvantages of these changes are:<br />
<br />
* The mangled name isn't kept<br />
<br />
The write of these files is made using CMake macros. These macros<br />
are in CSwig/WrapITK.cmake<br />
The CSwig/WrapType*.cmake files are help for the basic types and<br />
advanced types creation. These types are used define the template<br />
classes.<br />
<br />
== Wrapping a user-defined class ==<br />
<br />
The first change tails this second point : all files are genericly created.<br />
<br />
The project to create the corresponding libraries and files to a module<br />
is placed in a generic macro, generic in the sens that this macro independant<br />
to ITK.<br />
<br />
This macro and all used macros are placed in the CSwig/itkConfigWrapping.cmake<br />
file.<br />
<br />
So, if an user want wrap its own ITK class... or extent the wrapping of an existing<br />
ITK class, it must include the itkConfigWrapping.cmake and WrapITK.cmake<br />
files and use the corresponding macros to his work.<br />
<br />
In the itkWrapping CVS repository, there is an example to simply wrap my own<br />
class itkImageNothingFilter (easy filter that do nothing on the image). This<br />
example is completed with a Python test file.<br />
<br />
<br />
<br />
== Tree of templated classes ==<br />
<br />
The goal is to have a simplest and generic use of templated ITK classes.<br />
<br />
'''It's important to note that the previous use of classes is always available.''' This is only an advance (actually for Python, but may be generalized to Tcl and Java).<br />
<br />
Consider this python example :<br />
<br />
def write( itkImg, file ) :<br />
# typedef itk::ImageFileWriter< itkImg::Self > writerT<br />
writerT = itkImageFileWriter[ itkImg ]<br />
writer = writerT.New()<br />
writer.SetInput( itkImg )<br />
writer.SetFileName( file )<br />
writer.Update()<br />
<br />
This function will write an image (itkImg) in a file.<br />
But the writer creation is dependant to the itkImg type.<br />
The goal is : offer the possibility to the programmer to<br />
instanciate an ITK class without before known of the itkImg<br />
type.<br />
<br />
To have it, I will create a new class instance of<br />
itkPyTemplate type while the wrapping of the ITK classes.<br />
So, I will have :<br />
<br />
itkImage = itkPyTemplate("itkImage")<br />
<br />
For specific internal processing,<br />
The itkPyTemplate class can be used like a python dictionnary<br />
<br />
Next, I will call the set method on this new class instance to add<br />
different templates :<br />
<br />
itkImage.set("unsigned short,2",itkImageUS2)<br />
<br />
First parameter is the template type used as a key and the second<br />
parameter is the definition corresponding to the key.<br />
<br />
So, I can write :<br />
<br />
itkImage[itkUS,2]<br />
<br />
to get the itkImageUS2 class.<br />
After, I call the New method on this class and I get a class instance.<br />
<br />
The code of the itkPyTemplate class is at CSwig/Python/itkPyTemplate.py<br />
The code to generate these classes is written by CMake. It's<br />
in the resulting file : itkcommonaPy.py for the common part<br />
Last, we need call the itkcommonaPy module.<br />
<br />
All of these created python modules are imported in the itkPython.py file<br />
so, the user only needs to import the itkPython module use this advance<br />
In the CSwig/Tests/Python directory, I added the<br />
testTemplate.py and testTemplateUse.py files to test the class creation<br />
<br />
The code to write the itkcommonaPy.py file is in CSwig/WrapITKLang.cmake<br />
This code contains the WRITE_LANG_WRAP macro that will<br />
write these additionnal python classes<br />
<br />
This solution is actually only in python but it can be implemented for<br />
Java (I don't know if Tcl has classes... but a similar solution may be<br />
found).<br />
<br />
This patch can be removed by remove the code contained only in the macros<br />
in the CSwig/WrapITKLang.cmake file. But I think that patch is a usefull advance.<br />
<br />
{{ITK/Template/Footer}}</div>GduI1t