Commit Graph

9 Commits

Author SHA1 Message Date
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Jim Ingham d815c9ab88 Fix SBDebugger.GetOutputFileHandle() on OS X.
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
2016-03-11 01:57:45 +00:00
Zachary Turner 5de07b078d Be *stupider* about what constitutes a supported language binding.
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
2015-11-25 17:49:47 +00:00
Zachary Turner f6a30d3172 Fix build after swig_bot_lib changes.
llvm-svn: 254033
2015-11-24 22:27:02 +00:00
Zachary Turner a3037bd5f9 Create `lldbsuite.support.fs` and move `find_executable` there.
I have plans to reuse this function in another script, so raising
this out of prepare_bindings allows this.

llvm-svn: 253755
2015-11-21 01:39:04 +00:00
Todd Fiala f6508db485 Revert "prepare_bindings.py: enable static bindings"
This reverts commit 40f789f2dc6bb80fd25a33f91e452d081ed9d0ee.

llvm-svn: 253575
2015-11-19 16:56:12 +00:00
Todd Fiala d434a1d3e0 prepare_bindings.py: enable static bindings
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
2015-11-18 08:52:33 +00:00
Todd Fiala 9af81570c7 Added --find-swig option to allow searching for swig in path or other likely locations.
llvm-svn: 253346
2015-11-17 17:13:06 +00:00
Todd Fiala 84c72b6d75 Add Pythonic language binding wrapper generation script.
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
2015-11-17 07:17:38 +00:00