ITK python wrapping infrastructure allows external/remote modules to extend the available types for a specific class.
This has been heavily used when wrapping RTK for python, so that rtk python packages work with the pip-installable itk package. Here is an example of this approach, forcing wrapping of double with dimension 1 for itk::Point.
A first question would be: Is it the right way to go? Does itk provides other ways to specify additional templates?
We are now facing issues trying to extend itkPyBuffer. This class internally configures swig files to provide additional function definition.
It is possible to extend the wrapped types for itk::PyBuffer and its internal swig files the same way we did it for other itk classes.
The issues arises when the automatically generated file itkPyBuffer.i wants to include the configured file PyBuffer.i. This is triggered by “additional library files” being passed to swig through the WRAPPER_SWIG_LIBRARY_FILES variable.
This works perfectly when there is only one submodule (i.e. one class to wrap) in the current module.
This is the case for itkBridgeNumpy but not for RTK. Thus WRAPPER_SWIG_LIBRARY_FILES is propagated to every submodule being wrapped, which forces all generated swig file to include PyBuffer.i.
Multiple inclusion of the configured PyBuffer.i results in a mix of “%include” and “%import” calls in each class generated swig file, which ends up with no replacement of “%pythoncode” chunk where we expect it.
I can provide more information on this behavior if needed, but the only thing that is required is to be able to set WRAPPER_SWIG_LIBRARY_FILES at a submodule level in opposition to setting it for the whole module. Do you know any way to do this?
All the magic seem to happen in macro itk_end_wrap_module() and I could not find a way to decouple that for each submodule.
Hope everything I described makes sense, please do not hesitate if I missed something.
Any help would be appreciated.