| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Elimiates lots of unused code.
Reviewers: labath, mgorny
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68007
llvm-svn: 372895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The swig typemaps had some magic for output File *'s on OS X that made:
SBDebugger.GetOutputFileHandle()
actually work. That was protected by a "#ifdef __MACOSX__", but the corresponding define
got lost going from the Darwin shell scripts to the python scripts for running
swig, so the code was elided. I need to pass the define to SWIG, but only when
targetting Darwin.
So I added a target-platform argument to prepare_bindings, and if that
is Darwin, I pass -D__APPLE__ to swig, and that activates this code again, and
GetOutputFileHandle works again. Note, I only pass that argument for the Xcode
build. I'm sure it is possible to do that for cmake, but my cmake-foo is weak.
I should have been able to write a test for this by creating a debugger, setting the
output file handle to something file, writing to it, getting the output file handle
and reading it. But SetOutputFileHandle doesn't seem to work from Python, so I'd
have to write a pexpect test to test this, which I'd rather not do.
llvm-svn: 263183
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were trying to be super smart and find all the supported language
bindings. This led to us scanning the directory and treating all
subdirectories as language binding directories. This makes it
hard to add unrelated code in this folder.
Besides, we only support one at the moment - Python. And when new
ones are added it will be trivial to just add their names to a list.
So this patch gets stupider about how to look for language binding
subfolders. Just put them in a list, and use the list.
llvm-svn: 254078
|
| |
|
|
| |
llvm-svn: 254033
|
| |
|
|
|
|
|
| |
I have plans to reuse this function in another script, so raising
this out of prepare_bindings allows this.
llvm-svn: 253755
|
| |
|
|
|
|
| |
This reverts commit 40f789f2dc6bb80fd25a33f91e452d081ed9d0ee.
llvm-svn: 253575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new flag, --allow-static-binding. When specified,
if (and only if) the swig binary cannot be found, then the
LLDBWrapPython.cpp and lldb.py from the
scripts/Python/{static-binding-dir} are copied into the place where
swig would have generated them.
{static-binding-dir} defaults to static-binding, and can be
overridden with the --static-binding-dir command line argument.
The static bindings checked in are from r253424.
llvm-svn: 253448
|
| |
|
|
|
|
| |
locations.
llvm-svn: 253346
|
|
|
This is only used by Xcode at the moment. It replaces the
buildSwigWrapperClasses.py and related per-script-language
scripts. It also fixes a couple bugs in those w/r/t Xcode
usage:
* the presence of the GCC_PREPROCESSOR_DEFINITIONS env var
should not be short-circuiting generation of the language
binding; rather, only if LLDB_DISABLE_PYTHON is present
within that environment variable.
* some logic around what to do when building in "non-Makefile"
mode. I've switched the handling of that to be on a
"--framework" flag - if specified, we build an OS X-style
framework; otherwise, we go with non.
Putting this up now only attached to the Xcode build so
others can look at it but not be affected by it yet.
After this, I'll tackle the finalizer, along with trying
it locally on Linux.
llvm-svn: 253317
|