ITK/Release 4/Wrapping: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
|||
Line 60: | Line 60: | ||
* gccxml maintenance | * gccxml maintenance | ||
* | |||
who does it? | |||
migration to CLang? | |||
* migrating to WrapITK 0.3 | |||
* recode igenerator.py in C++ | * recode igenerator.py in C++ | ||
* support | * languages support | ||
* | ** keep python 2 | ||
* | ** keep java | ||
* | ** add C# | ||
* Default wrapped types and abbreviated naming scheme | ** add Python 3? | ||
** remove Tcl? | |||
* redefine the WrapITK libraries (grouping of classes) | |||
It seems to be tightly linked to [[ITK_Release_4/Modularization]]. | |||
* Default wrapped types and abbreviated naming scheme | |||
Some choices are already made for [[ITK_Release_4/SimpleITK | SimpleITK] | |||
* Wrapping coverage | * Wrapping coverage | ||
100% filters coverage? | |||
* Binary distribution | * Binary distribution | ||
* ITK Image to/from target language array conversion | * ITK Image to/from target language array conversion |
Revision as of 12:34, 11 August 2010
Wrapping
Requirements
- Avoid unnecessary dependencies
- Wrap +80% of the toolkit
- Have ITK look similar to the native wrapped language
Tools
- WrapITK
- Swig
- CableSwig
- MUMMY
Languages
What languages to wrap
- Python
- Lua ?
- Tcl ?
Discussions
Tcon July 19 2010
- Dropping CableSwig
- Using Swig Directly
- Along with GCC_XML
- Two Levels of Wrapping
- Wrapping the Simplified Layer (many wrapping tools will do)
- Wrapping the Templated Layer (WrapITK,GCC_XML)
- Managing multiple component images
- Microscopy use cases
- Remote Sensing cases
- itkVectorImage ?
- need a "component-by-component" filter driver ?
- Make easy to add new types (e.g. another pixel type for the image...)
- Run time binding may help here (along with the internal finder)
- Make possible (easy?) to distribute binaries of the wrapping.
- Maybe use the package manager (Ryppl ?).
- The same goes for the C++ version.
- Remove (or deprecate) itkSetVectorMacro and itkGetVectorMacro
they make the generated methods unusable in the target languages, and are not used that much in ITK
[glehmann@gbook build]$ grep -r etVectorMacro ~/src/Insight/Code/*/*.h | wc -l 34
They are used in two quite common filters - ChangeInformationImageFilter and PadImageFilter - and this makes this filter at least partly unusable in the target languages.
Agenda 081310
- gccxml maintenance
who does it? migration to CLang?
- migrating to WrapITK 0.3
- recode igenerator.py in C++
- languages support
- keep python 2
- keep java
- add C#
- add Python 3?
- remove Tcl?
- redefine the WrapITK libraries (grouping of classes)
It seems to be tightly linked to ITK_Release_4/Modularization.
- Default wrapped types and abbreviated naming scheme
Some choices are already made for [[ITK_Release_4/SimpleITK | SimpleITK]
- Wrapping coverage
100% filters coverage?
- Binary distribution
- ITK Image to/from target language array conversion
- Automatic Inline documentation
- Target language inheritance (SWIG directors)
- Automatic type selection in Python
- Improve 64bits support in ITK — surely done elsewhere already
- GDCM wrapping integration?