# Superbuild extension builds failed when Python was installed - good solution?

**URL:** <https://discourse.slicer.org/t/superbuild-extension-builds-failed-when-python-was-installed-good-solution/19938>\
**Category:** Development\
**Tags:** build, extensions\
**Created:** [September 30, 2021, 4:13pm UTC](https://discourse.slicer.org/t/superbuild-extension-builds-failed-when-python-was-installed-good-solution/19938 "2021-09-30T16:13:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cpinter](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/cpinter/32/7995_2.png) [@cpinter](https://discourse.slicer.org/u/cpinter)\
**Post date:** [September 30, 2021, 4:13pm UTC](https://discourse.slicer.org/t/superbuild-extension-builds-failed-when-python-was-installed-good-solution/19938/1 "2021-09-30T16:13:06Z")

</div>

Hi all,

I could not build first SlicerRT then SlicerOpenIGTLink today, and it seemed that the reason was a custom Python being installed on my Windows machine. See [Plastimatch build fails · Issue #198 · SlicerRt/SlicerRT · GitHub](https://github.com/SlicerRt/SlicerRT/issues/198)

After chatting with @lassoan we decided that we define the missing (and then after uninstalling the custom Python undefined) Python variables, see [COMP: Fix Plastimatch configuration if Python was installed · SlicerRt/SlicerRT@8b67847 · GitHub](https://github.com/SlicerRt/SlicerRT/commit/8b6784709356d6847bcbf7cfa647e48dce3ef2fc) and [COMP: Fix subproject configuration if Python was installed by cpinter · Pull Request #116 · openigtlink/SlicerOpenIGTLink · GitHub](https://github.com/openigtlink/SlicerOpenIGTLink/pull/116) .

My question is, mainly to @jcfr if there is a better solution for this, other than manually adding these variables to the subproject CMake files that fail to configure in this case. Thanks!

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 30, 2021, 4:49pm UTC](https://discourse.slicer.org/t/superbuild-extension-builds-failed-when-python-was-installed-good-solution/19938/2 "2021-09-30T16:49:18Z")

</div>

Currently, passing the variables is a sensible approach.

To streamline this, few possible approaches:

- (1) Update upstream VTK so that these variables are configured into `vtk-config` (or alike) and ensure project build against a VTK build tree would find the expected python. Now tracked in [https://gitlab.kitware.com/vtk/vtk/-/issues/18328](https://gitlab.kitware.com/vtk/vtk/-/issues/18328)
- (2) In case (1) doesn’t work out, update the Slicer/VTK fork to include relevant changes. Though … would prefer to minimize Slicer specific changes in our fork and try to only include backported changes.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 30, 2021, 4:55pm UTC](https://discourse.slicer.org/t/superbuild-extension-builds-failed-when-python-was-installed-good-solution/19938/3 "2021-09-30T16:55:03Z")

</div>

One of the challenge is that there are two ways to find python libraries:

- [FindPython](https://cmake.org/cmake/help/latest/module/FindPython.html)/[FindPython3](https://cmake.org/cmake/help/latest/module/FindPython3.html)
- [FindPythonInterp](https://cmake.org/cmake/help/latest/module/FindPythonInterp.html)/[FindPythonLibs](https://cmake.org/cmake/help/latest/module/FindPythonLibs.html) now deprecated

This is why we need to pass both set of variables ( `PYTHON_*` and `Python3_*`) and it may be challenging to have both sets configured into the VTK build tree …