SyneRBI
Need to switch to use CMake's FindPython
See https://github.com/CCPPETMR/SIRF/issues/504
For the SuperBuild, there's an additional problem that not all projects will use FindPython, so somehow we'll have to pass ${Python_EXECUTABLE} to PYTHON_EXECUTABLE. It's going to be messy...
Create Python_CMAKE_ARGS and probably define both Python_EXECUTABLE to PYTHON_EXECUTABLE
This is now pretty urgent, as recent CMake claims this support will be removed.
I've checked for remaining packages using the outdated FindPythonInterp.cmake. There's only 2
- https://github.com/TomographicImaging/CIL/issues/1835
- we're using TomoPhantom v2.0.0, which has that problem in its https://github.com/dkazanc/TomoPhantom/blob/v2.0.0/Wrappers/Python/CMakeLists.txt#L14 However, that whole directory no longer exists (v3.0 removed Cython wrappers), so presumably we could upgrade? @gfardell @paskino ?
In CIL we switched to find_python(Python COMPONENTS Interpreter) and CMake stopped finding the right python. Long story short, we need to pass the path to Python_Executable, see
- https://github.com/TomographicImaging/CIL/issues/2040
yes, of course. Once there are multiple Pythons around, it seems entirely down to luck if CMake finds the one you want. I'd assume it first tries "python" in your (shell) path, which would be fine in an activated conda env, but I don't know if that's really true, so generally recommend -DPython_EXECUTABLE=which python``. This is true for both the outdated and "new" style find_package() way to find python.
It's good to hear that CIL moved on. Maybe we should still cope with older CIL versions in the SB?
What about TomoPhantom? (Personally, I'd suggest to remove this from the default build, if it's still present, that is.)