[lldb-dev] LLDB Windows Python Bindings

[Zachary Turner via lldb-dev]

On Fri, Nov 20, 2015 at 10:05 AM Aidan Dodds <aidan at codeplay.com> wrote:

> First off thanks for opening that up to the mailing list, it will be good
> if discussion of this is useful to others.
>
> From the python 3.5 case:
> I'm not using ninja.build, but instead just compiling from the visual
> studio ide.  However, the custom build step I think you were referring to
> for finish_swig seems to be:
>
> setlocal
> "C:\Program Files (x86)\CMake\bin\cmake.exe" -E copy
> C:\Python35\python35.dll D:\rs_project\rs_llvm_build\$(Configuration)\bin
> if %errorlevel% neq 0 goto :cmEnd
> :cmEnd
> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
> :cmErrorLevel
> exit /b %1
> :cmDone
> if %errorlevel% neq 0 goto :VCEnd
>
>
> The exact error message for building finish_swig was the following:
>
> ------ Build started: Project: finish_swig, Configuration: Debug x64 ------
> Build started 20/11/2015 17:27:07.
> InitializeBuildStatus:
>   Touching "x64\Debug\finish_swig\finish_swig.tlog\unsuccessfulbuild".
> CustomBuild:
>   Python script sym-linking LLDB Python API
>   Traceback (most recent call last):
>     File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 383, in <module>
>       main(sys.argv[1:])
>     File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 326, in main
>       nResult, strMsg =
> run_post_process_for_each_script_supported(dictArgs)
>     File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 281, in run_post_process_for_each_script_supported
>       vDictArgs)
>     File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 223, in run_post_process
>       module = __import__(strModuleName)
>     File
> "d:\rs_project\rs_llvm\tools\lldb\scripts\python\finishSwigPythonLLDB.py",
> line 42, in <module>
>       import ctypes       # Invoke Windows API for creating symlinks
>     File "C:\Python35\lib\ctypes\__init__.py", line 7, in <module>
>       from _ctypes import Union, Structure, Array
>
>   ImportError: No module named '_ctypes'
>
Looks like this is an x64 build of LLDB, so it would need to be an x64
installation of Python 3.5  To be honest I haven't tested Python 3.5 with
x64, so I'm not sure what kind of issues might arise.  What happens if you
run C:\Python35\python_d.exe and then write "import ctypes".  Does it work?




>
>
> For the python 2.7 case:
>
> The error I see in CMake is the following:
>
> -- Found Python version 2.7.10+
>
> Unable to find C:/Python27/libs/python27+_d.lib
>
> Unable to find C:/Python27/libs/python27+.lib
>
> Unable to find C:/Python27/python27+_d.dll
>
> Unable to find C:/Python27/python27+.dll
>
> Python installation is corrupt. Python support will be disabled for this
> build.
>
Yea, I'm honestly not sure either.  I think you will need to do some CMake
debugging to figure this out.  Usually what I do is crack open the CMake
scripts and add some calls to the message() function at various points, to
see if you can figure out where this + is coming from.


>
> I'm not sure where the + comes from however...
>
> Aidan at AIDAN-PC /c/Python27
> $ python --version
> Python 2.7.10
>
> Aidan at AIDAN-PC /c/Python27
> $ python_d --version
> Python 2.7.10
>
This makes me think your'e using cygwin.  This isn't explicitly
unsupported, but also I don't know of anyone else Windows using cygwin, so
I can't guarantee there are no problems on the CMake side for cygwin
users.  If you do find some though, feel free to fix.


>
> As for the CMake options its again complicated because I'm using cmake-gui.
> Hopefully the relevant params are:
>
> PYTHON_EXCUTABLE = c:/python27/python_d.exe
> PYTHON_HOME = c:/python27
> LLDB_DISABLE_PYTHON = False
> LLDB_RELOCATABLE_PYTHON = False
> SWIG_DIR = d:/swig/lib
> SWIG_EXECUTABLE = d:/swig/swig.exe
> SWIG_VERSION = 3.0.5
>
>
> I am using Visual Studio 2013 and doing an x86_64 build.
> I compiled the python interpreter with the same version also.
>
> Its not a requirement for me to custom python for any reason, I just
> remember there being issues with using the release package.
>
Yea, what makes 2.7 so bad.  If you want to run the test suite, you have to
have a custom interpreter.  And then all the difficulty that goes along
with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151120/d14344b1/attachment.html>