Summary:
The current version of LLDB installs six.py into global python library directory. This approach produces conflicts downstream with distribution's py-six copy.
Introduce new configure option LLDB_USE_SYSTEM_SIX (disabled by default). Once specified as TRUE, six.py won't be installed to Python's directory.
Add new option in finishSwigWrapperClasses.py, namely --useSystemSix.
Sponsored by <The NetBSD Foundation>
Reviewers: mgorny, emaste, clayborg, joerg, labath
Reviewed By: labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29405
llvm-svn: 294071
Summary:
The NDK cmake toolchain file defines CMAKE_SYSTEM_NAME=Android, so switch the
build to use that. I have also updated the in-tree toolchain file to do that
(instead of defining __ANDROID_NDK__), so it can still be used to build.
After migrating the last bits of non-toolchainy bits out of the in-tree
toolchain, I intend to delete it.
Reviewers: tberghammer, danalbert
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D28775
llvm-svn: 292212
A combination of broken escaping in CMake and in the python swig
generation scripts meant that the swig generation step would fail
whenever there were spaces or special characters in parameters passed to
swig.
The fix for this in CMakeLists is to use the VERBATIM option on all
COMMAND-based custom builders relying on CMake to properly escape each
argument in the generated file.
Within the python swig scripts, the fix is to call subprocess.Popen with
a list of raw argument strings rather than ones that are incorrectly
manually escaped, then passed to a shell subprocess via
subprocess.Popen(' '.join(params)). This also prevents nasty things
happening such as accidental command-injection.
This allows us to have the swig / python executables in paths containing
special chars and spaces, (or on shared storage on Win32, e.g
\\some\path or C:\Program Files\swig\swig.exe).
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26757
llvm-svn: 289956
When building the LLDB Framework we need to ensure that the Python files get put into the Framework before the Framework's install target can be invoked.
All files inside the Framework's Resources bundle will get copied over during the install action.
llvm-svn: 289842
Summary:
This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library.
With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow.
The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step.
With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up.
Reviewers: zturner, tfiala
Subscribers: beanz, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24749
llvm-svn: 282110
This reverts commit r279296. Including LLDBDependencies breaks the
netbsd lldb bot because it exposes LLDB_USED_LIBS, which causes
lldb_link_common_libs to run to completion in unintended sites, which
results in a malformed call to target_link_libraries.
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/5989
Thanks to Chris Bieneman for figuring this out!
llvm-svn: 279322
It's pulling in all kinds of things it doesn't need (e.g, clang-tidy!).
Eliminating this dependency removes 1056 dependencies from the
'CommandObjectFrame.cpp.o' target and 454 dependencies from the 'lldb'
target. On my machine, this shaves 7 minutes off of a clean build of
lldb.
Thanks to Zachary Turner for pointing out some issues with an earlier
version of this patch!
Differential Revision: https://reviews.llvm.org/D22987
llvm-svn: 279296
Summary:
Building HEAD of LLDB fails in linking against DebugInfoPDB. It also prints the following warning:
```
CMake Warning (dev) in source/Plugins/SymbolFile/PDB/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
Target "lldbPluginSymbolFilePDB" has an INTERFACE_LINK_LIBRARIES property.
This should be preferred as the source of the link interface for this
library but because CMP0022 is not set CMake is ignoring the property and
using the link implementation as the link interface instead.
INTERFACE_LINK_LIBRARIES:
LLVMDebugInfoPDB
Link implementation:
(empty)
```
CMP0022 was introduced in CMake-2.8.11, bump minimal required version from 2.8 to 3.0 to gain more useful features like libexecinfo(3) detection on NetBSD.
Reviewers: emaste, zturner, labath
Subscribers: zturner, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D19685
llvm-svn: 268191
Summary:
Do not assume that liblldb.so is located in $(lldb -P)/../../../lib
when creating the _lldb python symlink. Instead, use the path passed
to LLVM_LIBDIR_SUFFIX, defaulting to $(lldb -P)/../../../lib when this
variable is not set.
Reviewers: vharron, emaste, zturner
Subscribers: zturner, labath, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19067
llvm-svn: 267462
This change does not introduce static bindings. It is simply using
the pylinted cleaned up code in prepare_bindings.py.
If this breaks anyting, I'll revert immediately and figure out what
needs to be addressed. I'm looking to wrap up
the cleanup aspect of the code change (pylinted, removal of code that
implements existing python stdlib code, fixes for Xcode adoption, etc.).
llvm-svn: 253478
When the readline target exists (only for non-Android Linux currently),
ensure that target is made a dependency of the finish_swig python-wrap-up
steps. This ensures it is built when building the lldb target.
Fixes:
https://llvm.org/bugs/show_bug.cgi?id=25038
llvm-svn: 249256
Summary:
After a developer builds LLDB from source on Windows (assuming they've built it with Python support enabled), they may be somewhat flustered when it fails to launch with a cryptic error.
{F890625}
This happens because Windows can't find python27.dll (or python27_d.dll in case LLDB was built in debug mode). Many developers may have previously installed a release build of Python 2.7 and will not notice anything is amiss when they run a release build of LLDB because Windows will load the python27.dll from one of the system directories or `PATH` (rather than the one that the LLDB build instructions tell them to build). The issue tends to be more pronounced with debug builds of LLDB, since fewer developers probably have python27_d.dll sitting in one of the Windows system directories.
To ensure Windows loads the correct custom built Python DLL when launching LLDB I've added a post-build event that copies the relevant DLL (based on the LLDB build configuration) from `PYTHON_HOME` to the directory in which the LLDB executable is generated.
Patch by Vadim Macagon. Thanks!
Reviewers: brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13237
llvm-svn: 248992
ninja lldb now does the following:
* forces the python post-build step to fire, which sets up the python lldb module properly.
* on Darwin and Linux, requires the lldb-server target to be built.
* on Darwin, requires the debugserver target to be built.
See http://reviews.llvm.org/D12899 for details.
llvm-svn: 247810
Summary:
This should be a mandatory build process going forward, if Python
is enabled. The longer term desire is to remove the old shell
scripts entirely.
Reviewers: zturner, clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12667
llvm-svn: 246979
Previously we would pass an argument to finishSwigWrapperClasses.py which
specified whether this was a debug or a release build. But sometimes
CMAKE_BUILD_TYPE would not be set to anything, causing this argument
to be empty when passed in. The only purpose of this argument was to
determine whether or not to append _d to the extension module when
creating the symlink. This is only necessary when doing a debug
build of LLDB on Windows, which implies a debug interpreter, so we
replace this with a check to see if the running interpreter is a debug
one, and append _d if so.
llvm-svn: 235559
Summary:
What looks like a typo has caused the scripts/Python directory to be compiled on non-Windows
platforms even with LLDB_DISABLE_PYTHON, which failed if Python.h was unavaiable. This changes
the condition to avoid compilation if LLDB_DISABLE_PYTHON is set.
Test Plan: Remove Python.h, verify compilation is successful.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8855
llvm-svn: 234319
This makes the directory structure mirror the canonical LLVM
directory structure for a gtest suite.
Additionally, this patch deletes the xcode project. Nobody
is currently depending on this, and it would be better to have
gtest unit tests be hand-maintained in the Xcode workspace
rather than using this python test runner. Patches to that
effect will be submitted as followups.
llvm-svn: 232211
The existing state of affairs was getting a little unwieldy.
All of LLDB's utility functions and initial configuration was in
the root CMake file. I split this up into 3 separate files and
moved them to relevant subfolders under cmake/modules.
Also, I deleted the add_lldb_definitions() function. It seemed
to be somewhat useless and did not serve any real purpose that
I was able to figure out.
llvm-svn: 231010
This resubmits r230380. The primary cause of the failure was
actually just a warning, which we can disable at the CMake level
in a followup patch on the LLVM side. The other thing which was
actually an error on the bot should be able to be fixed with
a clean.
llvm-svn: 230389
An OBJECT library is a special type of CMake library that produces
no archive, has no link interface, and no link inputs. It is like
a regular archive, just without the physical output. To link
against an OBJECT library, you reference it in the *source* file
list of a library using the special syntax $<TARGET_OBJECTS:lldbAPI>.
This will cause every object file to be passed to the linker
independently, as opposed to a single archive being passed to the
linker.
This is *extremely* important on Windows. lldbAPI exports all of the
SB classes using __declspec(dllexport). Unfortunately for technical
reasons it is not possible (well, extremely difficult) to get the
linker to propagate a __declspec(dllexport) attribute from a symbol
in an object file in an archive to a DLL that links against that
archive. The solution to this is for the DLL to link the object files
directly. So lldbAPI must be an OBJECT library.
This fixes an issue that has been present since the duplicated
lldbAPI file lists were removed, which would cause linker failures.
As a side effect, this also makes LLDB_DISABLE_PYTHON=1 work again
on Windows, which was previously totally broken.
llvm-svn: 230380
Embedding python with MSVC is very finicky, for reasons having
to do with the operating system's CRT, the implementation of
python itself on Windows, and even bugs in CMake.
One side effect of this is that we cannot rely on FindPythonLibs
and FindPythonInterp CMake functions to locate the correct
version of Python. We must instead manually specify the location
of PYTHON_LIBRARY and PYTHON_INCLUDE_DIR.
As a side effect, this fixes building LLDB in release mode by
specifying -DCMAKE_BUILD_TYPE=Release, which was previously
broken.
llvm-svn: 230262
Previously we would create the extension module as a post-build
step of creating liblldb. As part of this process, we created
symlinks and did other stuff.
This had several longstanding issues related to target
dependencies, such as not re-creating the symlink if liblldb.dll
failed to link, or if the build was Ctrl+C'ed from.
Then, the script that creates the symlinks began to grow to
include other things, such as argdumper, and it would try to
create symlinks before it had finished building the targets it
needed to symlink to.
This patches addresses all of these problems by creating an
explicit target for the script to run, and making it have a
dependency on all the targets it needs to create symlinks from/to.
llvm-svn: 229569
This reverts commit r226679. For some reason it was
not generating the same behavior as manually specifying
the include dir, library path, and exe path, and it was
causing the test suite to fail to run.
llvm-svn: 226683
CMake FindPythonLibs will look for multiple versions of Python
including both debug and release, and build up a list such as
(debug <debugpath> optimized <optimizedpath>). This confuses
the logic we have in CMake to copy the correct python dll to
the output directory so that it need not be in your system's PATH.
To alleviate this, we manually split this list and extract out
the debug and release versions of the python library, and copy
only the correct one to the output directory.
llvm-svn: 226679
BUILD_SHARED_LIBS=TRUE currently isn't working for Linux x86_64
This patch fixes the link errors and also some runtime errors
Test Plan:
CC=clang CXX=clang++ cmake -GNinja -DBUILD_SHARED_LIBS=TRUE -DCMAKE_LINKER=ld.gold -DCMAKE_BUILD_TYPE=Debug ../../llvm
ninja
ninja check-lldb
llvm-svn: 226039
variable (now provided both by the normal parent LLVM CMake files and by
the LLVMConfig.cmake file used by the standalone build).
This allows LLDB to build into and install into correctly suffixed
libdirs. This is especially significant for LLDB because the python
extension building done by CMake directly uses multilib suffixes when
the host OS does, and the host OS will not always look back and forth
between them. As a consequence, before LLVM, Clang, and LLDB (and every
other subproject) had support for using LLVM_LIBDIR_SUFFIX, you couldn't
build or install LLDB on a multilib system with its python extensions
enabled. With this patch (on top of all the others I have submitted
throughout the project), I'm finally able to build and install LLDB on
my system with Python support enabled. I'm also able to actually run the
LLDB test suite, etc. Now, a *huge* number of the tests still fail on my
Linux system, but hey, actually running them and them testing the
debugger is a huge step forward. =D
llvm-svn: 224930
the same way the LLVM CMake build does, notably using the proper CMake
module and specifically requesting an older Python version. LLDB relies
pretty heavily on not using Python 3 at this point, and without this
patch it ends up trying to use Python 3 which ends quite badly. =] With
this, I'm able to build LLDB in its standalone mode successfully on
Linux when I have both Python 2.7 and Python 3.3 installed.
llvm-svn: 224929
As a first step in addressing Bug #21921 this patch prefers
the python-based SWIG generation by default rather than the
shell-based SWIG generation any time python is enabled
(e.g. LLDB_DISABLE_PYTHON is 0).
Additionally, this patch changes the default value of
LLDB_DISABLE_PYTHON from 1 to 0 on Windows.
Anyone not using the CMake build is unaffected by this patch.
llvm-svn: 224543
This allows me to generate a Visual Studio solution that builds LLDB if
you have standalone builds of LLVM and Clang lying around.
Unfortunately, you have to pass *four* CMake variables in, but it means
you don't have to take the extra step of installing Clang and LLVM to
some package prefix.
Hopefully this will generate a more usable XCode project too.
llvm-svn: 221413
This patch fixes a number of issues with embedded Python on
Windows. In particular:
1) The script that builds the python modules was normalizing the
case of python filenames during copies. The module name is
the filename, and is case-sensitive, so this was breaking code.
2) Changes the build to not attempt to link against python27.lib
(e.g. the release library) when linking against msvcrt debug
library. Doing a debug build of LLDB with embedded python
support now requires you to provide your own self-compiled
debug version of python.
3) Don't import termios when initializing the interpreter. This
is part of a larger effort to remove the dependency on termios
since it is not available on Windows. This particular instance
was unnecessary and unused.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4441
llvm-svn: 212785
Teach add_lldb_library to correctly use the CMake 2.8.12
PUBLIC/PRIVATE/INTERFACE keywords. LLDB's CMake configuration would
inconsistently apply these keywords; this was previously a warning in
CMake 2.x but became an error in CMake 3.
llvm-svn: 212482
This change removes the ScriptInterpreter::TerminateInterpreter() call which
ended up endlessly calling itself as things currently stand. It also cleans
up some other Windows-related cmake changes.
See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011544.html
for more details.
Change by Zachary Turner
llvm-svn: 212320
Currently Windows disables Python builds by default. This
change ensures we don't process the scripts dir when we're
on Windows unless we're explicitly enabling python, which
prevents a build error.
Change by Deepak Panickal
llvm-svn: 212319
- Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms
- Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll
- More build fixes for Windows
The pending issues are that two Python modules, termios and pexpect are not available on Windows.
These are currently required for the Python command interpreter to be used from within LLDB.
llvm-svn: 212111
python bindings.
For example, this prevents errors on systems that disable python because
the system python isn't available. Without this, we still try to install
things and get install errors when that doesn't work.
llvm-svn: 211899
Change r210035 broke the Darwin cmake build. The
initial change was intended to stop the --start-group/--end-group
linker flags from being passed to non-gcc/clang-looking compilers,
stopping MSVC from warning on linking. That change, however,
caused MacOSX cmake-based builds to start using the --start-group/
--end-group flags, even though the MacOSX linker doesn't support
them. That broke the MacOSX clang build.
The fix keeps the newer check for a gcc-compatible compiler, but
specifically excludes MacOSX.
llvm-svn: 211123
Kamil Rytarowski