Commit Graph

86 Commits

Author SHA1 Message Date
Chris Bieneman e142631443 [CMake] Enable OS_LOG support on Darwin
This gets CMake to match the Xcode project build

llvm-svn: 309393
2017-07-28 15:39:50 +00:00
Chris Bieneman 4a1db1b037 [CMake] Fix framework build
The LLDB framework build looks for the swig-generated source in the wrong place. This should resolve that.

llvm-svn: 309023
2017-07-25 20:30:35 +00:00
Chris Bieneman 2246972ecc [CMake] Abstract Config.h generation for Xcode
This patch abstracts the generation of Config.h and creates a dummy project entry point to allow generation of LLDB's Config header without performing a full CMake configuration.

This will enable the Xcode project to generate LLDB's Config header.

llvm-svn: 301553
2017-04-27 16:04:26 +00:00
Kamil Rytarowski 4791532830 Install six.py conditionally
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
2017-02-04 00:20:24 +00:00
Pavel Labath e5cfc67113 [cmake] Make lldb build with the android ndk toolchain file
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
2017-01-17 11:55:00 +00:00
Chris Bieneman 095f633b74 [CMake] Fix finding LLDBWrapPython.cpp in Framework build
The framework build was constructing the path to LLDBWrapPython incorrectly. It is apparently always in the scripts directory.

llvm-svn: 291788
2017-01-12 18:45:59 +00:00
Luke Drummond c3d0165c49 Fix broken escaping of commands in the build
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
2016-12-16 16:38:25 +00:00
Chris Bieneman 1662da2832 [CMake] Ensure Python files are inside the LLDB framework bundle
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
2016-12-15 18:19:10 +00:00
Chris Bieneman d3199f5ed2 [CMake] Initial support for LLDB.framework
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
2016-09-21 21:02:16 +00:00
Vedant Kumar e62b54ed2a Revert "[lldb][cmake] Remove libclang as an lldbBase dependency (NFCI)"
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
2016-08-19 21:00:40 +00:00
Vedant Kumar 181f924beb [lldb][cmake] Remove libclang as an lldbBase dependency (NFCI)
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
2016-08-19 18:41:50 +00:00
Chris Bieneman c12cabb4f4 [CMake] Update to requiring CMake 3.4.3
Summary:
This is as per the discussions on developer lists:

http://lists.llvm.org/pipermail/llvm-dev/2016-April/098780.html
http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D20826

llvm-svn: 271328
2016-05-31 20:21:44 +00:00
Kamil Rytarowski 90db606429 Fix NetBSD build with CMake 3.5.2
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
2016-05-01 10:23:24 +00:00
Francis Ricci 4692f52daa Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is used
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
2016-04-25 20:34:34 +00:00
Zachary Turner cc2e76d57f Fix CMake dependency on lldb.py
llvm-svn: 253501
2015-11-18 21:09:55 +00:00
Todd Fiala 7d1da7e91c Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.
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
2015-11-18 17:36:15 +00:00
Pavel Labath 6e813bbf27 Fixup lldb-argdumper cmake build
forgot to rename in one spot.

llvm-svn: 251628
2015-10-29 14:14:24 +00:00
Chaoren Lin 6c85598c5a Fix Android build.
llvm-svn: 249486
2015-10-07 00:01:06 +00:00
Ryan Brown 702c4b865e Simple readline functionality for interactive python on linux.
Differential Revision: http://reviews.llvm.org/D13268

llvm-svn: 249478
2015-10-06 22:21:08 +00:00
Todd Fiala 65b9056f3d cmake: ensure readline python module target is added before finishing swig.
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
2015-10-04 01:28:51 +00:00
Bruce Mitchener f0248ca545 Add a Post-Build Event on Windows to copy the correct custom Python DLL to the LLDB binaries dir
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
2015-10-01 07:55:44 +00:00
Todd Fiala 509300d94c cmake fixes for lldb target.
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
2015-09-16 15:34:06 +00:00
Bruce Mitchener 2f9aa57927 [cmake] Remove LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION.
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
2015-09-08 05:00:22 +00:00
Pavel Labath 6512cad8e5 Standalone cmake build improvements (bug #23889)
patch by Eugene Zelenko.

llvm-svn: 242529
2015-07-17 15:50:48 +00:00
Zachary Turner 0405d68bb4 Use the debugginess of the python interpreter when symlinking _lldb.pyd.
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
2015-04-22 22:53:18 +00:00
Pavel Labath 76d5df132a Remove check for windows when compiling scripts directory
this is a followup to r234319, change requested in http://reviews.llvm.org/D8855.

llvm-svn: 234321
2015-04-07 15:30:23 +00:00
Pavel Labath e4651eb033 Don't compile scripts directory if LLDB_DISABLE_PYTHON is set
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
2015-04-07 14:55:11 +00:00
Zachary Turner 891af04d82 Create a check-lldb-unit target to run unit tests.
llvm-svn: 232212
2015-03-13 20:55:07 +00:00
Zachary Turner 719ec93a74 Rework the gtest directory structure.
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
2015-03-13 20:54:57 +00:00
Zachary Turner 26d7fcfc38 Create a CMake build for the gtest unit tests.
llvm-svn: 232210
2015-03-13 20:54:21 +00:00
Zachary Turner 44a14d95c2 [CMake] Refactor LLDB main CMake file.
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
2015-03-02 20:45:26 +00:00
Zachary Turner d64412beb8 [CMake] Clean up lldb-mi CMakeLists.txt.
It was maintaining two huge file lists that are identical except
for 1 file.  Make this work the proper way.

llvm-svn: 230398
2015-02-24 23:36:12 +00:00
Zachary Turner 030b8cb413 Resubmit "[CMake] Change lldbAPI to be a CMake OBJECT library."
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
2015-02-24 22:17:57 +00:00
Zachary Turner 0980447a5f Revert "[CMake] Change lldbAPI to be a CMake OBJECT library."
This reverts commit r230380.  It causes CMake to fail on certain
machines with an error about needing to use string(STRIP_GENEX).

llvm-svn: 230382
2015-02-24 21:28:01 +00:00
Zachary Turner f4f8740eb0 [CMake] Change lldbAPI to be a CMake OBJECT library.
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
2015-02-24 20:58:39 +00:00
Zachary Turner d487bb12d9 [CMake] On Windows, require manual specification of python libs.
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
2015-02-23 21:20:59 +00:00
Zachary Turner aeda626d80 [CMake] Create a custom target for generating extension module.
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
2015-02-17 22:20:29 +00:00
Zachary Turner 02b882a69b Revert "Some fixes for linking Python on Windows."
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
2015-01-21 18:30:40 +00:00
Zachary Turner f3a7da349c Some fixes for linking Python on Windows.
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
2015-01-21 17:53:10 +00:00
Vince Harron 4d2857321d Fixes compilation/run error with BUILD_SHARED_LIBS=TRUE
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
2015-01-14 21:01:15 +00:00
Chandler Carruth 875d3bb538 [cmake/multilib] Teach LLDB to respect the multlib LLVM_LIBDIR_SUFFIX
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
2014-12-29 12:42:33 +00:00
Chandler Carruth e471e1363e [cmake] Teach the standalone CMake build to find the Python interpreter
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
2014-12-29 12:32:27 +00:00
Zachary Turner f27ae73617 Always use python-based SWIG generation script for CMake.
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
2014-12-18 21:25:53 +00:00
Shawn Best 8da0bf3b7c LLGS Android target support - for Andy Chien : http://reviews.llvm.org/D6166
llvm-svn: 221570
2014-11-08 01:41:49 +00:00
Reid Kleckner ee3c175e6b cmake: Make the LLDB standalone build work for me
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
2014-11-05 23:23:18 +00:00
Saleem Abdulrasool e1401eb747 build: fix cmake warning with newer CMake
Hoist the compatibility macros out a level and re-use them when adding link
dependencies.  Silences a warning from CMake.

llvm-svn: 213469
2014-07-20 05:28:55 +00:00
Zachary Turner 0ab4b48992 Get the python scripting interface working on Windows.
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
2014-07-10 23:47:42 +00:00
David Majnemer aea50ce97c CMake: Let LLDB build with CMake 3
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
2014-07-07 20:29:00 +00:00
Todd Fiala 1b67c66c9c Windows build fixes and removal of endlessly recursive termination function.
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
2014-07-04 06:58:01 +00:00
Todd Fiala 8422c5ae6d Fix Windows build when python is not explicitly enabled
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
2014-07-04 06:43:47 +00:00