With Slicer_BUILD_ITKPython and Slicer_INSTALL_ITKPython turned on and using CMake 3.18.4 and latest Slicer master I get some errors during the wrapping process. Has anyone successfully built ITKPython recently?
I was looking into turning on ITK python support as a default in Slicer since it has matured in the past year and half. This would support future python development using import itk instead of relying on SimpleITK when using python. This seems to be the preferred trend to support more development using Python. I considered pip installing ITK, but since Slicer at times uses a custom ITK build or at least a custom configuration it seemed necessary to build the ITK python package just like we build the SimpleITK python package for the same reason.
Some of my build errors (build still continuing)
33> Generating ../../itkDCMTKImageIO.xml
33>C:/S5R-nightly/ITK-build/Wrapping/itkDCMTKImageIO.cxx(31,18): error GCCDED198: no type named 'DCMTKImageIOFactory' in namespace 'itk' [C:\S5R-nightly\ITK-build\Wrapping\Modules\ITKIODCMTK\ITKIODCMTKCastXML.vcxproj]
33> typedef itk::DCMTKImageIOFactory itkDCMTKImageIOFactory;
33> ~~~~~^
33>C:/S5R-nightly/ITK-build/Wrapping/itkDCMTKImageIO.cxx(32,18): error G1A4676F8: no member named 'DCMTKImageIOFactory' in namespace 'itk' [C:\S5R-nightly\ITK-build\Wrapping\Modules\ITKIODCMTK\ITKIODCMTKCastXML.vcxproj]
33> typedef itk::DCMTKImageIOFactory::Pointer itkDCMTKImageIOFactory_Pointer;
33> ~~~~~^
33>C:/S5R-nightly/ITK-build/Wrapping/itkDCMTKImageIO.cxx(34,18): error GCCDED198: no type named 'DCMTKSeriesFileNames' in namespace 'itk' [C:\S5R-nightly\ITK-build\Wrapping\Modules\ITKIODCMTK\ITKIODCMTKCastXML.vcxproj]
33> typedef itk::DCMTKSeriesFileNames itkDCMTKSeriesFileNames;
33> ~~~~~^
33>C:/S5R-nightly/ITK-build/Wrapping/itkDCMTKImageIO.cxx(35,18): error G1A4676F8: no member named 'DCMTKSeriesFileNames' in namespace 'itk' [C:\S5R-nightly\ITK-build\Wrapping\Modules\ITKIODCMTK\ITKIODCMTKCastXML.vcxproj]
33> typedef itk::DCMTKSeriesFileNames::Pointer itkDCMTKSeriesFileNames_Pointer;
33> ~~~~~^
33> 4 errors generated.
We should be able to use the pre-built ITK Python binary packages via pip install – the Slicer CMake configuration could be updated to do this by default.
This is good to consider, but the way the ITK Python binaries are built, there will not be
conflicts with the Slicer ITK C++ libraries.
This is likely related to a DCMTK CMake configuration issue, maybe there is a better hint earlier in the build log.
@thewtex I was considering cases where in the past Slicer has issued an ITK commit change to its Slicer ITK fork for immediate use in the Slicer preview build. Then the developer might want to use that fix from the ITK python interface. Or maybe this is an incorrect assumption? I guess we could work around and say the fix is immediately available in C++, but must wait for a newer pre-built ITK Python package. Thoughts on this @lassoan?
Seems like in the past the use of the Slicer ITK fork was to wait on merge approval of a fix in ITK and also not have to update other Slicer code/dependencies due to other ITK code changes by backporting onto a known working commit.
Since there is no reliable way to ensure binary compatibility between C++ libraries, we need to build Slicer’s ITK.
However, it is possible to create binary compatible Python packages, so for ITK Python we have the option of building and bundling it with Slicer or using a prebuilt package. While building and bundling ITK Python with Slicer has some advantages (we can choose to build it with the options we want, what data types are supported, we can apply patches immediately) there are also some disadvantages (forces us to deal with ITK Python build, makes Slicer core larger, takes longer to build, our special build might work differently from default ITK, etc.). Overall, using pre-built ITK Python looks a more favorable option to me.
Yes. ITK Python is all statically linked, nothing is exposed from ITK.
What I don’t like very much about the current situation is that users may end up with having 3 copies of ITKs in Slicer: ITK C++, SimpleITK, and ITK Python. It just seems highly redundant. But maybe nowadays this is acceptable price to pay for some convenience and freedom to choice (you can use different ITK Python and SimpleITK versions).
Maybe we could decide to not bundle SimpleITK with Slicer and it would be downloaded/installed from PyPI when needed (e.g., when the user opens Simple Filters module). It would then somewhat reduce the redundancy.
For quite some time, there were two commits added on top of ITK that were specific to Slicer’s build configuration, but all substantial changes were integrated into the upstream ITK repository. However, currently, Slicer is using upstream ITK: