# Build error when building ITKPython

**URL:** <https://discourse.slicer.org/t/build-error-when-building-itkpython/15302>\
**Category:** Support\
**Tags:** itk-python\
**Created:** [January 1, 2021, 2:39am UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302 "2021-01-01T02:39:49Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [January 1, 2021, 2:39am UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/1 "2021-01-01T02:39:49Z")

</div>

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)

```auto
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.

```

---

<div class="post-metadata">

**Author:** ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)\
**Post date:** [January 6, 2021, 3:34pm UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/2 "2021-01-06T15:34:10Z")

</div>

Hi @jamesobutler,

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.

> [@jamesobutler](#):
>
> 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

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.

> [@jamesobutler](#):
>
> ```auto
> 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;
> 
> ```

This is likely related to a DCMTK CMake configuration issue, maybe there is a better hint earlier in the build log.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [January 6, 2021, 6:25pm UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/3 "2021-01-06T18:25:20Z")

</div>

@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.

I’ll try to look into the DCMTK CMake issue. I was looking how [https://github.com/InsightSoftwareConsortium/ITKPythonPackage](https://github.com/InsightSoftwareConsortium/ITKPythonPackage) was creating the wheels, but was going to try the current Slicer ITKPython wrapping cmake option. Does in general this look to be correct? See the current latest code:  
[https://github.com/Slicer/Slicer/blob/bc4a07dc408089328f359436de05c3e440f7a39e/SuperBuild/External\_ITK.cmake#L153](https://github.com/Slicer/Slicer/blob/bc4a07dc408089328f359436de05c3e440f7a39e/SuperBuild/External_ITK.cmake#L153)  
[https://github.com/Slicer/Slicer/blob/bc4a07dc408089328f359436de05c3e440f7a39e/SuperBuild/External\_ITK.cmake#L73-L98](https://github.com/Slicer/Slicer/blob/bc4a07dc408089328f359436de05c3e440f7a39e/SuperBuild/External_ITK.cmake#L73-L98)

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [January 6, 2021, 6:30pm UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/4 "2021-01-06T18:30:01Z")

</div>

Similarly, can ITK Python and SimpleITK (python) both be installed without conflicts if they are using different ITK versions?

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [January 6, 2021, 6:57pm UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/5 "2021-01-06T18:57:22Z")

</div>

> [@jamesobutler](#):
>
> 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.

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.

> [@jamesobutler](#):
>
> can ITK Python and SimpleITK (python) both be installed without conflicts if they are using different ITK versions?

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.

---

<div class="post-metadata">

**Author:** ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)\
**Post date:** [January 7, 2021, 1:52pm UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/6 "2021-01-07T13:52:25Z")

</div>

> [@jamesobutler](#):
>
> @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

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:

> <https://github.com/Slicer/Slicer/blob/88a4b7d84f0186becbadb8aac4f976ff89288e3a/SuperBuild/External_ITK.cmake#L33>

> [Slicer/SuperBuild/External\_ITK.cmake at bc4a07dc408089328f359436de05c3e440f7a39e · Slicer/Slicer · GitHub](https://github.com/Slicer/Slicer/blob/bc4a07dc408089328f359436de05c3e440f7a39e/SuperBuild/External_ITK.cmake#L73-L98)

Overall, it looks OK. However, I agree with @lassoan: in practice, using pre-built binaries is practically a good, workable approach to pursue.

> [@jamesobutler](#):
>
> I’ll try to look into the DCMTK CMake issue.

Thanks, @jamesobutler. We may want to create an `itk-iodcmtk` binary Python package similar to the many other ITK module Python packages.

---

<div class="post-metadata">

**Author:** ![jcrudy](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcrudy/32/12610_2.png) [@jcrudy](https://discourse.slicer.org/u/jcrudy)\
**Post date:** [September 29, 2021, 7:25pm UTC](https://discourse.slicer.org/t/build-error-when-building-itkpython/15302/7 "2021-09-29T19:25:21Z")

</div>

I hit the same problem: [Building v5.2.1 fails on itkDCMTKImageIO.cxx · Issue #2762 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/issues/2762)  
I did find a potential solution, which I mentioned in the thread on the github issue.