[vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake?

[David Gobbi]

Hi Andrew,

You ask questions that are difficult to answer.  I'll spend some time going
over the code and reminding myself of why things are the way they are,
but I won't have a full reply for you before the weekend.

Off the top of my head: the fact that vtkWrapPython.cmake is used in odd
places to indirectly call FindPythonLibs is bad.  Someone got lazy and put
put some code they shouldn't have into vtkWrapPython.cmake, and that
required vtkWrapPython.cmake to be used in odd places or else debug
builds would break.

I disagree that using the CMake version of FindPythonLibs.cmake is better:

1) The very fact that FindPythonLibs.cmake and FindPythonInterp.cmake are
two independent scripts has been a source of trouble (it make
synchronization
between the library and the interpreter difficult).  So if there are going
to be
substantial changes, I'd rather make a new script "FindPython.cmake" and see
if the cmake folks are willing to adopt it.

2) We've often been saved by the fact that we have our own script, because
in the past we've run into situations where we've needed to patch the
script.
(Also, in the past we did a better job of synchronizing such changes with
the
cmake repository.)

3) I don't think there's a way to block cmake's FindPythonLibs.cmake from
finding python3, and that's a real problem for us until VTK supports
python3.

So my preference would be to change FindPythonLibs.cmake so that it solves
your specific issue (so that it finds your python).  Eventually, when we
make
the move to python3, we can consider either making a new "FindPython.cmake"
script, or syncing with the CMake script.

 - David


On Wed, Mar 18, 2015 at 10:30 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Hi Folks,
>
> I would really like some input from those familiar with how Python is
> found and wrapped on VTK.
>
> I came across a problem where FindPythonLibs.cmake [the VTK version]
> cannot find the python include directory or the python lib. However the
> CMake version seems to work OK. This happens if Python is installed in a
> users directory and not a system directory.
>
> My thinking is that instead of just modifying the VTK version it would be
> better to just use the CMake version.
>
> What I think happens is that during the configuration process:
> 1) In the top-level CMakeLists.txt - PythonInterp is found.
> 2) ... groups and dependencies set up and defined ...
> 3) Utilities/Python/CMakeLists.txt - including vtkWrapPython
> vtkWrapPython.cmake
> FindPythonLibs
> Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found version
> "2.7.8")
> Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found suitable
> version "2.7.8", minimum required is "2")
> 4) ... HDF5 stuff ...
> 5) vtkPythonWrapping.cmake
>    FindPythonLibs
>    Not building mpi4py on Windows (not supported currently).
>    vtkPythonWrapping.cmake
>    FindPythonLibs
>    vtkWrapPython.cmake
>    FindPythonLibs
>
> Can someone explain why there has to be so many calls to FindPythonLibs?
> One oddity that you can see above is that
> ./Utilities/Python/CMakeLists.txt calls vtkWrapPython only to call
> FindPythonLibs. Which makes me think that: Is it safe, in the top-level
> CMakeLists.txt to do the FindPythonLibs just the once?
>
> It is clear that
> ./CMake/vtkPythonWrapping.cmake
> ./CMake/vtkWrapPython.cmake
> both call FindPythonLibs which may also be redundant.
>
> I am working on a branch to do this so any input from the original writers
> would be appreciated.
> It would also be really appreciated if they would act as reviewers.
>
> Regards
>    Andrew
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150318/9662e401/attachment.html>