<div dir="ltr">Hi Andrew,<div><br></div><div>You ask questions that are difficult to answer.  I'll spend some time going</div><div>over the code and reminding myself of why things are the way they are,</div><div>but I won't have a full reply for you before the weekend.</div><div><br></div><div>Off the top of my head: the fact that vtkWrapPython.cmake is used in odd</div><div>places to indirectly call FindPythonLibs is bad.  Someone got lazy and put</div><div>put some code they shouldn't have into vtkWrapPython.cmake, and that</div><div>required vtkWrapPython.cmake to be used in odd places or else debug</div><div>builds would break.</div><div><br></div><div>I disagree that using the CMake version of FindPythonLibs.cmake is better:</div><div><br></div><div>1) The very fact that FindPythonLibs.cmake and FindPythonInterp.cmake are</div><div>two independent scripts has been a source of trouble (it make synchronization</div><div>between the library and the interpreter difficult).  So if there are going to be</div><div>substantial changes, I'd rather make a new script "FindPython.cmake" and see</div><div>if the cmake folks are willing to adopt it. </div><div><div class="gmail_extra"><br></div><div class="gmail_extra">2) We've often been saved by the fact that we have our own script, because</div><div class="gmail_extra">in the past we've run into situations where we've needed to patch the script.</div><div class="gmail_extra">(Also, in the past we did a better job of synchronizing such changes with the</div><div class="gmail_extra">cmake repository.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">3) I don't think there's a way to block cmake's FindPythonLibs.cmake from</div><div class="gmail_extra">finding python3, and that's a real problem for us until VTK supports python3.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So my preference would be to change FindPythonLibs.cmake so that it solves</div><div class="gmail_extra">your specific issue (so that it finds your python).  Eventually, when we make</div><div class="gmail_extra">the move to python3, we can consider either making a new "FindPython.cmake"</div><div class="gmail_extra">script, or syncing with the CMake script.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> - David</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 10:30 PM, Andrew Maclean <span dir="ltr"><<a href="mailto:andrew.amaclean@gmail.com" target="_blank">andrew.amaclean@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Folks,</div><div><br></div><div>I would really like some input from those familiar with how Python is found and wrapped on VTK.</div><div><br></div><div>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.</div><div><br></div><div>My thinking is that instead of just modifying the VTK version it would be better to just use the CMake version.</div><div><br></div><div>What I think happens is that during the configuration process:</div><div>1) In the top-level CMakeLists.txt - PythonInterp is found.</div><div>2) ... groups and dependencies set up and defined ...</div><div>3) Utilities/Python/CMakeLists.txt - including vtkWrapPython</div><div>vtkWrapPython.cmake</div><div>FindPythonLibs</div><div>Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found version "2.7.8") </div><div>Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found suitable version "2.7.8", minimum required is "2") </div><div>4) ... HDF5 stuff ...</div><div>5) vtkPythonWrapping.cmake</div><div>   FindPythonLibs</div><div>   Not building mpi4py on Windows (not supported currently).</div><div>   vtkPythonWrapping.cmake</div><div>   FindPythonLibs</div><div>   vtkWrapPython.cmake</div><div>   FindPythonLibs</div><div><br></div><div>Can someone explain why there has to be so many calls to FindPythonLibs?</div><div>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?</div><div><br></div><div>It is clear that</div><div>./CMake/vtkPythonWrapping.cmake</div><div>./CMake/vtkWrapPython.cmake</div><div>both call FindPythonLibs which may also be redundant.</div><div><br></div><div>I am working on a branch to do this so any input from the original writers would be appreciated.</div><div>It would also be really appreciated if they would act as reviewers.</div><div><br></div><div>Regards</div><span class="HOEnZb"><font color="#888888"><div>   Andrew</div><div><br></div><div><br></div>-- <br><div>___________________________________________<br>Andrew J. P. Maclean<br><br>___________________________________________</div></font></span></div></blockquote></div><br></div></div></div>