amccarth added a comment. An aside ...
I'm still trying to get back to a buildable state the earlier changes, like the one that tries to enforce version consistency between the libs and the interpreter. I'm currently bisecting to figure out what I hope is the final blocker. For me, the find_package(PythonInterp) call was always finding the older interpreter (2.7) even though everything pointed to the newer one (3.6). That tripped the version compatibility check that was recently added. The algorithm used by find_package isn't well documented (as far as I can tell), so I couldn't even tell you whether it was doing the wrong thing. I can tell you that the version check seemed unnecessary, as lldb built and tested fine when I locally removed that check, despite the fact that the versions didn't match. The only way I was able to make things work again was to completely remove Python 2.7 from my machine. Oddly, the uninstaller also took make with it, so then I couldn't run lldb tests. With make re-installed, I now have a some crashes during tests to the Python allocator being called without the GIL being held. I'm currently bisecting to figure out which change caused that. This crash is especially painful, as it leaves an invisible Python process running and holding files open, which breaks subsequent builds. To your question ... Without understanding how either version of find_package finds Python, it's hard to say whether it solves the problems outlined in Zach's comment at the top of find_python_libs. Zach's first two points don't apply anymore, as we're well past MSVC 2015. But the third one, regarding a 32-bit CMake being able to find a 64-bit Python, seems like it would still be a problem. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64881/new/ https://reviews.llvm.org/D64881 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
