One more problem.  Compiled successfully, and ran LLDB.  Upon startup I get
this warning:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named lldb.embedded_interpreter
(lldb)

So something is wrong there.  Typing "script" with no arguments gives this:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined

Just curious, what has been your use case for this so far?  Do you have it
working on your end?  If so, what kind of things can you successfully do
with it?


On Tue, Jul 1, 2014 at 4:52 PM, Deepak Panickal <[email protected]> wrote:

>  Thanks, I'll look into the CMake warning.
>
> For now, you have to enable the variable
> LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION specifically to use the new
> python scripts, when LLDB_DISABLE_PYTHON is disabled.
> Which is why not using the variable would break the build on Windows. On
> Linux, it would work both ways.
>
> I added this variable so that the new scripts can be tested without
> affecting normal builds on other platforms.
> Could you please try,
> cmake* -DLLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION=1*
> -DLLDB_DISABLE_PYTHON=0 -DPYTHON_INCLUDE_DIR=c:\python27\include
> -DPYTHON_LIBRARY=C:\Python27\libs\python27.lib ..\..
>
> Thanks,
> Deepak
>
>
> On 01/07/2014 23:56, Zachary Turner wrote:
>
> Also getting the following error:
>
>  For reference, I ran cmake as
>
>  cmake -DLLDB_DISABLE_PYTHON=0 -DPYTHON_INCLUDE_DIR=c:\python27\include
> -DPYTHON_LIBRARY=C:\Python27\libs\python27.lib ..\..
>
>  D:\src\llvm\build\ninja>ninja lldb
> [88/433] Building lldb python wrapper
> FAILED: cmd.exe /c cd /D D:\src\llvm\build\ninja\tools\lldb\scripts && env
> PYTHON_EXECUTABLE=C:/Python27/python.exe
> D:/src/llvm/tools/lldb/scripts/build-swig-wrapper-classes.sh
> D:/src/llvm/tools/lldb D:/src/llvm/build/ninja/tools/lldb/scripts
> D:/src/llvm/build/ninja/tools/lldb/scripts D:/src/llvm/bu
> ild/ninja -m && env PYTHON_EXECUTABLE=C:/Python27/python.exe
> D:/src/llvm/tools/lldb/scripts/finish-swig-wrapper-classes.sh
> D:/src/llvm/tools/lldb D:/src/llvm/build/ninja/tools/lldb/scripts
> D:/src/llvm/build/ninja/tools/lldb/scripts D:/src/llvm/build/ninja -m
> env: D:/src/llvm/tools/lldb/scripts/build-swig-wrapper-classes.sh: Exec
> format error
> [88/433] Building CXX object
> tools\lldb\source\Plugins\Process\mach-core\CMakeFiles\lldbPluginProcessMachCore.dir\ProcessMachCore.cpp.obj
> ninja: build stopped: subcommand failed.
>
>
>
> On Tue, Jul 1, 2014 at 3:41 PM, Zachary Turner <[email protected]> wrote:
>
>> I get the following warning when running cmake with no special options
>> passed via -D
>>
>>  CMake Warning (dev) at tools/lldb/CMakeLists.txt:234
>> (target_link_libraries):
>>   Policy CMP0023 is not set: Plain and keyword target_link_libraries
>>   signatures cannot be mixed.  Run "cmake --help-policy CMP0023" for
>> policy
>>   details.  Use the cmake_policy command to set the policy and suppress
>> this
>>   warning.
>>
>>    The keyword signature for target_link_libraries has already been used
>> with
>>   the target "liblldb".  All uses of target_link_libraries with a target
>>   should be either all-keyword or all-plain.
>>
>>    The uses of the keyword signature are here:
>>
>>     * cmake/modules/AddLLVM.cmake:331 (target_link_libraries)
>>
>>  Call Stack (most recent call first):
>>    tools/lldb/source/CMakeLists.txt:214 (add_lldb_library)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>>
>> On Tue, Jul 1, 2014 at 10:54 AM, Deepak Panickal <[email protected]>
>> wrote:
>>
>>>  Hi,
>>>
>>> I'm planning to upstream the Windows Python API changes now.
>>>
>>> This has been done by completely rewriting the shell scripts used for
>>> the API generation in Python so that it's portable across different
>>> platforms. We have tested it on both Windows and Linux successfully.
>>>
>>> I have added a new CMake variable
>>> "LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION", to control if the new
>>> Python scripts for managing SWIG generating the API are enabled or not.
>>> This is disabled by default to not impact other platforms. This variable
>>> can be removed once we move all the platforms to the Python scripts from
>>> the shell scripts. There's some cleanup to be done, which I'll be working
>>> on.
>>>
>>> Please let me know if there are any issues or comments.
>>>
>>> Thanks,
>>> Deepak
>>>
>>>
>>> On 24/06/14 12:23, Deepak Panickal wrote:
>>>
>>> Yes, it was compiling with MSVC 2013. It hasn't been updated though
>>> since the review was submitted.
>>> We're working on it now, so should be fixed to current tip and
>>> upstreamed soon.
>>>
>>> Thanks,
>>> Deepak
>>>
>>> On 24/06/14 01:24, Zachary Turner wrote:
>>>
>>> By the way, does this compile with MSVC 2013?  Many of the changes I had
>>> to make to get things compiling don't seem to be present in this patch.
>>>
>>>
>>>  On Mon, Jun 23, 2014 at 5:16 PM, Zachary Turner <[email protected]>
>>> wrote:
>>>
>>>> Interesting.  I had already made some progress towards this in my own
>>>> branch, so I'll have a look.
>>>>
>>>>  BTW, I'm not sure what your solution was regarding the missing python
>>>> modules, but the pexpect one in particualr is pretty trivial to fix.  Just
>>>> change it to subprocess.run() and remove the import of pexpect.
>>>>
>>>>
>>>> On Mon, Jun 23, 2014 at 5:09 PM, Deepak Panickal <[email protected]>
>>>> wrote:
>>>>
>>>>>  We have already ported the lldb.py generating scripts to Python for
>>>>> portability and got the API working in Windows and Linux.
>>>>> We can load an ELF file, dump symbols, do remote debugging etc.
>>>>> This work has been put into review sometime ago, so might need some
>>>>> updation.
>>>>>
>>>>> http://reviews.llvm.org/D2980
>>>>> <http://llvm-reviews.chandlerc.com/D2980>
>>>>>
>>>>> We're planning to fix it up quite soon to match with the current tip.
>>>>>
>>>>> Thanks,
>>>>> Deepak
>>>>>
>>>>>
>>>>> On 23/06/2014 22:09, Zachary Turner wrote:
>>>>>
>>>>> I'm already volunteering, just want to make sure it's ok before I do
>>>>> the work :)
>>>>>
>>>>>  That being said, Greg mentions in an earlier message that it might
>>>>> not be possible because we wish to support a Python-less build.   Who uses
>>>>> this out of curiosity?  I don't think any Windows developers mind
>>>>> installing Python as a requirement.  It's also mentioned on the Building
>>>>> LLDB page (http://lldb.llvm.org/build.html) that Python is a
>>>>> dependency
>>>>>
>>>>>
>>>>> On Mon, Jun 23, 2014 at 2:07 PM, Todd Fiala <[email protected]> wrote:
>>>>>
>>>>>> You can volunteer to write it more portably ;-)
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 23, 2014 at 1:55 PM, Zachary Turner <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hmm, a shell script.  kind of a non-starter for Windows.  Any reason
>>>>>>> this can't be a python script?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 23, 2014 at 1:52 PM, Greg Clayton <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It is generated by running swig with many options. See:
>>>>>>>>
>>>>>>>> lldb/scripts/build-swig-wrapper-classes.sh
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> > On Jun 23, 2014, at 1:41 PM, Zachary Turner <[email protected]>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > I'm trying to get the test suite into a working state on windows,
>>>>>>>> or at the very least get it to the point where it fails by saying that 
>>>>>>>> none
>>>>>>>> of the tests are supported on this platform.  I seem to be missing this
>>>>>>>> file lldb.py though.  Is it supposed to be in the tree, or is it 
>>>>>>>> generated
>>>>>>>> somehow?
>>>>>>>>  > _______________________________________________
>>>>>>>> > lldb-dev mailing list
>>>>>>>> > [email protected]
>>>>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> lldb-dev mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>   --
>>>>>>   Todd Fiala |  Software Engineer |  [email protected] |
>>>>>> 650-943-3180
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lldb-dev mailing 
>>>>> [email protected]http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> [email protected]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing 
>>> [email protected]http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>
>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to