ITK/Release 4/Wrapping/Tasks

Done

Build WrapITK with ccache

• Documentation: Using CCache for WrapITK

MetadataDictionary access from target languages

• modify itkMetaDataDictionary.h to add those methods:

 + MetaDataObjectBase::Pointer & Get(const std::string &) const;
 + void Set(const std::string &, MetaDataObjectBase * );
 + std::vector< std::string > Keys() const;

• add a specific language customization for python, to make the metadata accessible in a more usual way.

 + a __setitem__() method to add/modify a metadata in the dictionary
 + a __len__() method to return the number of metadata in the dictionary
 + a __getitem__() method - this one should take care to down cast the object to its real type
 + a __str__() method to print the content of the dictionary
 + a __iter__() method to return every elements in the dictionary one by one

Fix Installation

• Option ${CMAKE_INSTALL_PREFIX}/lib/ITK-4.0/ accepted in the ITK developers list
  • Put all wrapITK libraries here along with libraries of other packages. We won't require versioned names.

In Progress

Tcl SmartPointers

Look at how SmartPointers are replaced by swig proxy objects in python and java and explore the possibility to do the same in Tcl to decrease the build time of WrapITK.

Remove the USE_WRAP_ITK option

• Enabling a language in cmake should be enough.

Build swig as an external project

• As it's done for gccxml.
• If you look in the gerrit abandoned patch, you will find a change proposed by Kent Williams which can be partially reused.

Integrate WrapITK in the ITK modularization

• First step - Restructure the WrapITK Libraries directory to look it similar to the Modules directory here
• remove the USE_WRAP_ITK

Pending Tasks

Ongoing

• (*)[GL-05a] [ITK-2528] - [95%] - Redefine the WrapITK libraries, (follow modular, no need monolithic anymore) (gaetan)
• [GL-05b] [??] - [--%] - Move the wrapitk wrapping files (.wrap) directly in the corresponding modules
• [GL-05c] [??] - [--?] - Use the module mechanism to trigger wrapping.

Oraganisation

SWIG is a tool for making it easy to expose C/C++ code for use from a variety of high level programming languages. The idea is to feed C/C++ header files into SWIG and SWIG then generates the 'glue' code so that your C/C++ library can be used from another language such as Python, Java, C#, Ruby, Perl etc. Currently, there are implementations for supporting over 20 different target languages. Please visit SWIG's home page at http://www.swig.org.

Ready for Beta / Meeting MICCAI / 15th September

• [GL-03] [ITK-2530] - [--%] - Port the SWIG interface gen. to C++, (alex)
• [GL-09] [ITK-2531] - [33%] - Binary distribution, (alex)
  • one full build, sub package ( python, java, tcl, dev (cmake, swig interfaces, ...) ) independently installable, possible to distribute
  • generation with CPack
• [GL-07] [ITK-2539] – [75%] - Extend support to more types, (unsigned long for win 64 ) (Alex)

Ready for 15 october

• (*)[GL-02] [ITK-2532] - [--%] - Add support for C#, (gaethan)
• [GL-04] [ITK-2533] - [--%] - Add support for Python 3, (gaetan)

Ready for 15 November

• [GL-10] [ITK-2534] – [--%] - language specific array conversion, (NOTE: simple itk did it for C# and java, we have it in python) (python almost done, java and C# is being worked out in simpleITK, wait for them) (gaethan) (depends on C#)
• [GL-13] [ITK-2536] - [--%] - Target language inheritance, swig expertise, all languages (gaethan) (need C# and python3)
• [GL-14] [ITK-2529] - [--%] - Automatic type selection in Python, (gaetan)
• [GL-12] [ITK-2535] - [--%] - Automatic Inline documentation, done in python, prototype existing in Java. all is done in python, so we need to port it to C++ (see GL-03) (alex?)
• [GL-17] [ITK-2537] – [--%] - Documentation (user guide) (all)
• [GL-18] [ITK-2538] – [--%] - Documentation (dev. Guide) (all)

NOTE

• gcc-xml => does not work under MSVC 2008 and 2010 !!