ITK/Release 4/Wrapping: Difference between revisions
Agouaillard (talk | contribs) |
Agouaillard (talk | contribs) |
||
Line 42: | Line 42: | ||
= Discussions and TConfs = | = Discussions and TConfs = | ||
* 19-07-2010 - NoAgenda - [/19072010_Minutes|Minutes] | |||
== Tcon 808310 == | == Tcon 808310 == |
Revision as of 14:53, 1 May 2011
Wrapping
High-Level Goals
SIMPLIFY ITK by allowing easy access of the toolkit from other languages, especially scripting languages, hiding some difficulties (templates, compilation ...) along the way.
Metrics
- Avoid unnecessary dependencies (see Modular ITK)
- FASTER
- faster compilation
- limited compilation ( see modular itk v4 )
- faster re-compile (touching a given .h should not trigger a full re-compilation)
- Wrap 80%+ of the toolkit
- Have ITK behaves in the different languages as close to the native code as possible
Languages
- Java
- Python
- Lua ?
- Tcl ?
- see simpleITK
Required Tools and Technology
Installation is detailled here
tools
- WrapITK.
- Swig
- GccXML
WrapITK Configuration and Build Process Internals
Parallel Build Status
Discussions and TConfs
- 19-07-2010 - NoAgenda - [/19072010_Minutes|Minutes]
Tcon 808310
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 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?
Minutes 081310
Attendees
- Luis Ibañez
- Gabe Hart
- Gaëtan Lehmann
- Brad King
Topics
- gccxml maintenance
Brad working on it. Getting harder with newer compiler. Will probably possible for the next couple of years.
CLang must be explored as a replacement.
- migrating to WrapITK 0.3
- recode igenerator.py in C++
reuse cable code. already read gccxml output.
- languages support
- keep python 2
- keep java
- add C#
- add Python 3? maybe
- remove Tcl? sure
- redefine the WrapITK libraries (grouping of classes)
use the same module organization than in ITK
- Default wrapped types and abbreviated naming scheme
- Wrapping coverage
- Binary distribution
distribute binary for now next move to ryppl
- 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
remove 64 bit pixel type
rework filter using unsigned long type
- GDCM wrapping integration?
add interfaces in ITK classes and wrap those classes