Commit Graph

184 Commits

Author SHA1 Message Date
Alex Langford babcbaf971 [CMake] Fix subtle CMake bug
CMake specifies that the DEPENDS field of add_custom_target is for files
and output of add_custom_command. In order to add a target dependency,
add_dependencies should be used.

llvm-svn: 359490
2019-04-29 19:44:43 +00:00
Jonas Devlieghere 8c3513ffc4 [Docs] Generate the python reference without building all of LLDB
As discussed on the mailing list, we should be able to generate the
Python reference without building all of LLDB. To make that possible I
create a dummy python package, which is then parsed by epydoc. The
latter will complain that it couldn't import lldb, but that doesn't
matter as far as generation of the docs is concerned.

Differential revision: https://reviews.llvm.org/D61216

llvm-svn: 359465
2019-04-29 16:29:10 +00:00
Michal Gorny 9c3824aad7 [lldb] [lit] Add feature flags for native CPU features
Add a new lit-cpuid tool that detects CPU features used by some of
the tests, and use it to populate available_features in lit.  For now,
this means that the test for MM/XMM register read will be run only
when the host CPU support SSE instruction set.  However, this is going
to make it possible to introduce additional tests relying on AVX.

Differential Revision: https://reviews.llvm.org/D61073

llvm-svn: 359303
2019-04-26 13:21:46 +00:00
Davide Italiano 5f4c6dcc11 [Cmake] Add missing dependency for running tests.
This is needed now that we marked lldb-test as EXCLUDE_ALL, to
make sure `ninja lldb-test-deps` doesn't fail.

llvm-svn: 358625
2019-04-17 23:43:01 +00:00
Jorge Gorbe Moya d7aba76783 Add lldb-vscode as a dependency of lldb tests.
Summary:
In the current state, 'ninja check-lldb' runs the lldb-vscode tests, but it
won't rebuild lldb-vscode if any of its sources has changed. This is very
confusing when you fix something and the tests keep failing, or vice versa.

Reviewers: clayborg

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D59828

llvm-svn: 357016
2019-03-26 18:36:44 +00:00
Pavel Labath 5d4d168c3c [cmake] Move LLDB_DISABLE_LIBEDIT handling code into a central place
This was previously scattered between the main CMakeLists.txt file and
LLDBGenerateConfig.cmake and LLDBConfig.cmake. This caused the some of
the code to be executed in incorrect order. Specifically, the check for
el_winsertstr was done before libedit_LIBRARIES was computed, and so it
always failed on the first run.

Moving it the two checks to a central place makes sure this doesn't
happen again and improves the overall readability.

llvm-svn: 355103
2019-02-28 16:04:54 +00:00
Pavel Labath 105f949149 Set cmake policy CMP0075 to NEW
Summary:
The policy is about cmake_include_files ignoring
CMAKE_REQUIRED_LIBRARIES in the OLD behavior. Llvm already sets this
policy to NEW, but that is overridden by our cmake_minimum_required
command.

This makes our cmake policy setup consistent with the llvm build files
and avoids a warning when using newer versions of cmake.

Reviewers: sgraenitz, xiaobai

Subscribers: mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D58279

llvm-svn: 354251
2019-02-18 10:09:29 +00:00
Jonas Devlieghere 201a40c568 [CMake] Make lldb-test-deps a dependency of check-lldb
We have a custom target for lldb's test dependencies but it must have
gotten lost in one of the recent CMake refactorings.

llvm-svn: 353978
2019-02-13 20:51:13 +00:00
Jonas Devlieghere 9d0c5f9953 Define _ENABLE_EXTENDED_ALIGNED_STORAGE on Windows.
Apparently there are multiple places where MSVC complains about
instantiations with extended aligment. I think it's better to define
`_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message.

I don't have access to a Windows machine so this is all speculative.

llvm-svn: 353778
2019-02-12 00:30:21 +00:00
Jonas Devlieghere 1e6ba23608 [lldb-instr] Make lldb-instr a test dependency
llvm-svn: 353444
2019-02-07 18:41:59 +00:00
Jonas Devlieghere 43977e8aa9 [CMake] Fix lldb-test-depends target
The lldb-test-depends target was using the old CMake variable name
LLDB_TEST_DEPENDS instead of LLDB_TEST_DEPS. This patch moves the target
definition and makes it use the correct one.

llvm-svn: 351489
2019-01-17 22:25:20 +00:00
Stefan Granitz bb3df52c0c [CMake] Include tests by default also in standalone builds
In-tree builds include tests by default. Standalone builds should behave the same.

llvm-svn: 350945
2019-01-11 18:11:04 +00:00
Stefan Granitz cfdbad065e [CMake] Remove dead code and outdated comments
Summary: All of these changes are NOPs.

Reviewers: stella.stamenova, labath, JDevlieghere

Reviewed By: stella.stamenova

Subscribers: mgorny, lldb-commits, #lldb

Differential Revision: https://reviews.llvm.org/D56609

llvm-svn: 350937
2019-01-11 17:51:33 +00:00
Stefan Granitz 79f41967dc [CMake] In standalone builds, LLVM_BINARY_DIR should point to LLVM's binary directory
Summary: In standalone builds `LLVM_BINARY_DIR` was equal to `LLDB_BINARY_DIR` so far. This is counterintuitive and invalidated the values of `LLDB_DEFAULT_TEST_DSYMUTIL/FILECHECK/COMPILER` etc.

Reviewers: zturner, labath, clayborg, JDevlieghere, stella.stamenova, serge-sans-paille

Reviewed By: labath

Subscribers: mgorny, friss, lldb-commits, #lldb

Differential Revision: https://reviews.llvm.org/D56443

llvm-svn: 350738
2019-01-09 16:25:37 +00:00
Stefan Granitz 644a3289e7 [CMake] Fix standalone builds: workaround the cxx target not getting imported yet (unlike clang target)
Summary: Handle standalone builds separately and print a warning if we have no libcxx.

Reviewers: aprantl, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: mgorny, lldb-commits, #lldb

Differential Revision: https://reviews.llvm.org/D56399

llvm-svn: 350737
2019-01-09 16:25:31 +00:00
Stefan Granitz f9ef9e0c19 [CMake] Python bindings generation polishing
Summary:
Simplify SWIG invocation and handling of generated files.

The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory.

Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai

Reviewed By: aprantl

Subscribers: mgorny, lldb-commits, #lldb

Differential Revision: https://reviews.llvm.org/D55332

llvm-svn: 350393
2019-01-04 12:47:02 +00:00
Stefan Granitz f126ce6881 [CMake] Revised LLDB.framework builds
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.

Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)

Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle

Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath

Reviewed By: aprantl

Subscribers: friss, mgorny, lldb-commits, #lldb

Differential Revision: https://reviews.llvm.org/D55328

llvm-svn: 350391
2019-01-04 12:46:50 +00:00
Stefan Granitz fd6fedfbe0 [CMake] Aggregate options for LLDB in LLDBConfig.cmake
Summary: In preparation for LLDB.framework changes, collect options for LLDB in LLDBConfig.cmake (used for both, standalone and in-tree builds of LLDB).

Reviewers: JDevlieghere, aprantl, xiaobai

Reviewed By: aprantl

Subscribers: srhines, mgorny, lldb-commits, #lldb

Differential Revision: https://reviews.llvm.org/D55317

llvm-svn: 350389
2019-01-04 12:46:34 +00:00
Stefan Granitz 90aeb4c8d9 [CMake] Streamline code signing for debugserver #2
Summary:
Major fixes after D54476 (use Diff1 as base for comparison to see only recent changes):
* In standalone builds target directory for debugserver must be LLDB's bin, not LLVM's bin
* Default identity for code signing must not force-override LLVM_CODESIGNING_IDENTITY globally

We have a lot of cases, make them explicit:

* ID used for code signing (debugserver and in tests):
** `LLDB_CODESIGN_IDENTITY` if set explicitly, or otherwise
** `LLVM_CODESIGNING_IDENTITY` if set explicitly, or otherwise
** `lldb_codesign` as the default

* On Darwin we have a debugserver target that:

* On other systems, the debugserver target is not defined, which is equivalent to **[3A]**

Common configurations on Darwin:
* **[1A]** `cmake -GNinja ../llvm` builds debugserver from source and signs with `lldb_codesign`, no code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[1A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_CODESIGN_IDENTITY=lldb_codesign ../llvm` builds debugserver from source and signs with `lldb_codesign`, ad-hoc code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[2A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_USE_SYSTEM_DEBUGSERVER=ON ../llvm` copies debugserver from system, ad-hoc code signing for other binaries (prints status: //Copy system debugserver from: /path/to/system/debugserver//)
* **[2B]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- ../llvm` same, but prints additional warning: //Cannot code sign debugserver with identity '-'. Will fall back to system's debugserver. Pass -DLLDB_CODESIGN_IDENTITY=lldb_codesign to override the LLVM value for debugserver.//
* **[3A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_NO_DEBUGSERVER=ON ../llvm` debugserver not available (prints status: //lldb debugserver will not be available)//

Reviewers: JDevlieghere, beanz, davide, vsk, aprantl, labath

Reviewed By: JDevlieghere, labath

Subscribers: mgorny, #lldb, lldb-commits

Differential Revision: https://reviews.llvm.org/D55013

llvm-svn: 350388
2019-01-04 12:46:30 +00:00
Jonas Devlieghere 26bbd810b2 [CMake] Don't require libcxxabi on darwin
Just libcxx should suffice.

llvm-svn: 349546
2018-12-18 21:40:05 +00:00
Jonas Devlieghere deb54f1b24 [cmake] Make libcxx(abi) a dependency when building in-tree clang for macOS
As discussed on IRC this morning, when building an in-tree clang for
testing we have to have libcxx and libcxxabi checked out. This is a
common pitfall. Not only are the resulting failures non-obvious, they
only manifest when running the test suite, *after* building lldb and
clang. By making them a hard dependency (on macOS) we fail earlier with
a more useful error message.

Differential revision: https://reviews.llvm.org/D55837

llvm-svn: 349539
2018-12-18 20:59:23 +00:00
Stefan Granitz 3d00002ea2 [CMake] Fix side-effect from LLDB_VERSION change in r346668 for framework-enabled builds
llvm-svn: 348360
2018-12-05 12:18:44 +00:00
Davide Italiano 3bd249018c Revert "[CMake] Streamline code signing for debugserver and pass entitlements to extended llvm_codesign"
It breaks the lldb cmake bots.

llvm-svn: 347619
2018-11-27 00:25:49 +00:00
Stefan Granitz 6e6b4ac18e [CMake] Streamline code signing for debugserver and pass entitlements to extended llvm_codesign
Summary:
Use llvm_codesign to sign debugserver with entitlements.
Set global LLVM_CODESIGNING_IDENTITY from LLDB_CODESIGN_IDENTITY (if given).
Pass through ENTITLEMENTS from add_lldb_executable to add_llvm_executable.
Handle reconfigurations correctly.

We have a lot of cases, make them explicit:

(1) build and sign debugserver, if all conditions apply:
* LLDB_NO_DEBUGSERVER=OFF (default)
* On Darwin: LLDB_USE_SYSTEM_DEBUGSERVER=OFF (default)
* On Darwin: LLVM_CODESIGNING_IDENTITY == lldb_codesign

(2) use system debugserver, if on Darwin and any of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and found on system (explicit case)
* LLVM_CODESIGNING_IDENTITY != lldb_codesign and found on system (fallback case)

(3) debugserver will not be available, in case of:
* LLDB_NO_DEBUGSERVER=ON
* On Darwin: LLVM_CODESIGNING_IDENTITY != lldb_codesign and not found on system

(4) error state, in case of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and not found on system
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and LLDB_NO_DEBUGSERVER=ON

Reviewers: xiaobai, beanz, vsk, JDevlieghere

Subscribers: mgorny, lldb-commits, llvm-commits

Differential Revision: https://reviews.llvm.org/D54476

llvm-svn: 347305
2018-11-20 14:10:33 +00:00
Stefan Granitz de62b76c51 [CMake] Allow version overrides with -DLLDB_VERSION_MAJOR/MINOR/PATCH/SUFFIX
Summary:
This follows the approach in Clang. If no overrides are given, LLDB_VERSION_* is inferred from LLVM_VERSION_*. This mimics the current behaviour (PACKAGE_VERSION itself is generated from LLVM_VERSION_*).
For in-tree builds LLVM_VERSION_* will be defined at this point already. For standalone builds, LLDBConfig.cmake is included after LLDBStandalone.cmake which includes LLVMConfig.cmake.

Reviewers: labath, xiaobai

Subscribers: mgorny, friss, aprantl, lldb-commits

Differential Revision: https://reviews.llvm.org/D54333

llvm-svn: 346668
2018-11-12 16:22:28 +00:00
Vedant Kumar 9b13bea61a Allow use of self.filecheck in LLDB tests (c.f self.expect)
Add a "filecheck" method to the LLDB test base. This allows test authors
to pattern match command output using FileCheck, making it possible to
write stricter tests than what `self.expect` allows.

For context (motivation, examples of stricter checking, etc), see the
lldb-dev thread: "Using FileCheck in lldb inline tests".

Differential Revision: https://reviews.llvm.org/D50751

llvm-svn: 342508
2018-09-18 19:31:47 +00:00
Alex Langford 36706fd977 Introduce install-lldb-framework target
Summary:
Previously, I thought that install-liblldb would fail because CMake had
a bug related to installing frameworks. In actuality, I misunderstood the
semantics of `add_custom_target`: the DEPENDS option refers to specific files,
not targets. Therefore `install-liblldb` should rely on the actual liblldb
getting generated rather than the target.

This means that the previous patch I committed (to stop relying on CMake's
framework support) is no longer needed and has been reverted. Using CMake's
framework support greatly simplifies the implementation.

`install-lldb-framework` (and the stripped variant) is as simple as
depending on `install-liblldb` because CMake knows that liblldb was built as a
framework and will install the whole framework for you. The stripped variant
will depend on the stripped variants of individual tools only to ensure they
actually are stripped as well.

Reviewers: labath, sas

Subscribers: mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D50038

llvm-svn: 338594
2018-08-01 17:21:18 +00:00
Alex Langford 2f6a1018e0 Revert "Stop building liblldb with CMake's framework functionality"
This reverts r338154. This change is actually unnecessary, as the CMake
bug I referred to was actually not a bug but a misunderstanding of
CMake.

Original Differential Revision: https://reviews.llvm.org/D49888

llvm-svn: 338178
2018-07-27 23:38:58 +00:00
Alex Langford c1d4311c1b Stop building liblldb with CMake's framework functionality
Summary:
CMake has a bug in its ninja generator that prevents you from
installing targets that are built with framework support. Therefore, I want to
not rely on CMake's framework support.
See https://gitlab.kitware.com/cmake/cmake/issues/18216

Differential Revision: https://reviews.llvm.org/D49888

llvm-svn: 338154
2018-07-27 19:41:17 +00:00
Alex Langford 97ba3b64dd Invert dependency between lldb-framework and lldb-suite
Summary:
Currently, if you build lldb-framework the entire framework doesn't
actually build. In order to build the entire framework, you need to actually
build lldb-suite. This abstraction doesn't feel quite right because
lldb-framework truly does depend on lldb-suite (liblldb + related tools).

In this change I want to invert their dependency. This will mean that lldb and
finish_swig will depend on lldb-framework in a framework build, and lldb-suite
otherwise. Instead of adding conditional logic everywhere to handle this, I
introduce LLDB_SUITE_TARGET to handle it.

Differential Revision: https://reviews.llvm.org/D49406

llvm-svn: 337311
2018-07-17 18:28:51 +00:00
Jonas Devlieghere 441d289a5c [CMake] Remove redundant path component
Fixes spurious path component introduced in r336278. The variable is
cached so might require you to re-run CMake.

llvm-svn: 336279
2018-07-04 14:38:21 +00:00
Jonas Devlieghere cfc2377333 [CMake] Use LLVM_RUNTIME_OUTPUT_INTDIR for LLDB exectuable
Apparently there's a difference between using LLVM_RUNTIME_OUTPUT_INTDIR
and LLVM_BINARY_DIR. The former will point to the current binary
directory (i.e. that where lldb is built) while the former will always
point to LLVM's. This was causing trouble for the swift build but should
be a transparent for upstream lldb.

llvm-svn: 336278
2018-07-04 14:34:32 +00:00
Jonas Devlieghere 60cbbb4440 [CMake] Move some variables around
This improves consistency by creating a CMake variable for the dsymutil
path. The motivation is that for Swift, the dsymutil binary and the lldb
binary live in different directories and we need an option to configure
this from the build script.

llvm-svn: 336272
2018-07-04 13:59:25 +00:00
Pavel Labath 8779968805 Attempt to fix windows build broken by r334968
The issue was that there was no dependency from lldb-suite target to liblldb in
the no-framework scenario. This caused the finish-swig target to be executed
prematurely and fail (because it cannot copy liblldb to the python folder). On
other platforms this did not matter because there just creates a symlink.

The extra lldb-suite -> liblldb edge should fix this. Technically, I could add
this just to the !framework case as the framework target will take care of the
transitive dep, but it seemed more clear to make the dep unconditional.

llvm-svn: 335047
2018-06-19 14:23:31 +00:00
Alex Langford f66a36d2dc Fix up Info.plist when building LLDB.framework with CMake
Summary:
We weren't using the Info.plist template in resources previously.
When using that template, some of the key's values weren't being populated
because some variables were not being defined. In one case, CMake didn't
like the substring expansion syntax of CFBundleIdentifier so I got rid of that.

Differential Revision: https://reviews.llvm.org/D47792

llvm-svn: 335014
2018-06-19 02:59:30 +00:00
Alex Langford 27510c18ad Introduce lldb-framework CMake target and centralize its logic
Summary:
In this patch I aim to do the following:

1) Create an lldb-framework target that acts as the target that handles generating LLDB.framework. Previously, liblldb acted as the target for generating the framework in addition to generating the actual lldb library. This made the target feel overloaded.
2) Centralize framework generation as much as it makes sense to do so.
3) Create a target lldb-suite, which depends on every tool and library that makes liblldb fully functional. One result of having this target is it makes tracking dependencies much clearer.

Differential Revision: https://reviews.llvm.org/D48060

llvm-svn: 334968
2018-06-18 18:27:16 +00:00
Alex Langford 372e3d3e12 Remove commented out line from top-level CMakeLists.txt
llvm-svn: 334225
2018-06-07 20:17:46 +00:00
Alex Langford 59ad87821a Change SWIG output directory when building LLDB.framework with CMake
Instead of assuming that SWIG generated files (e.g. lldb.py) will live
in scripts, we should set it to $LLDB_PYTHON_TARGET_DIR. This variable is set to
scripts, except when building LLDB.framework when it is set to
LLDB_FRAMEWORK_DIR.

Differential Revision: https://reviews.llvm.org/D47742

llvm-svn: 333968
2018-06-04 23:47:36 +00:00
Jonas Devlieghere f6c870a794 [test] Fix --framework argument passed to dotest.
The framework argument was broken when I removed the generator
expressions upstream.  I replaced $<TARGET_FILE_DIR:liblldb> with
${LLVM_LIBRARY_OUTPUT_INTDIR}) which is not correct.

rdar://40534649

llvm-svn: 333412
2018-05-29 12:30:27 +00:00
Saleem Abdulrasool 9426358ea1 build: use cmake to find the libedit content
Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.

llvm-svn: 333041
2018-05-22 23:24:46 +00:00
Jonas Devlieghere 52721286b2 [CMake] Unify and relayer testing
This patch restructures part of LLDB's testing configuration:

1. I moved the test dependencies up the chain so every dotest dependency
   becomes a lit dependency as well. It wouldn't make sense for dotest to
   have other dependencies when it's being run by lit. Lit on the other
   hand can still specify extra dependencies.

2. I replaced as much generator expressions with variables as possible.
   This is consistent with the rest of LLVM and doesn't break generators
   that support multiple targets (MSVC, Xcode). This wasn't a problem
   before, but now we need to expand the dotest arguments in the lit
   configuration and there's only one test suite even with multiple
   targets.

3. I moved lldb-dotest into it's own directory under utils since there's
   no need anymore for it to located under `test/`.

Differential revision: https://reviews.llvm.org/D46334

llvm-svn: 331463
2018-05-03 16:54:10 +00:00
Aaron Smith 07482d32e7 [lit] Update how clang and other binaries are found in per-configuration directories
Summary:
This is modeled after the clang and llvm lit tests.

Several properties have CMAKE_CFG_INTDIR as part of the path - this works correctly when the cmake generator only supports one configuration which is known at configuration time, but it does not work correctly when the cmake generator supports multiple configurations (for example, VS). 

For VS, CMAKE_CFG_INTDIR ends up set as $Configuration and then it is never updated correctly. Instead, the lit configuration can use a property that can be overwritten at run time. AddLLVM does that for several properties (such as LLVM_TOOLS_DIR). 

This change is also removing properties from the lit/CMakeLists.txt that are actually set during the call to configure_lit_site_cfg

Reviewers: zturner, lldb-commits

Reviewed By: zturner

Subscribers: llvm-commits, labath, stella.stamenova, mgorny, hintonda

Differential Revision: https://reviews.llvm.org/D43096

llvm-svn: 325652
2018-02-21 00:05:51 +00:00
Don Hinton d8a6b90e83 [cmake] Fix LLDB_CODESIGN_IDENTITY logic.
Summary:
Consolidate LLDB_CODESIGN_IDENTITY logic in one place and use
SKIP_DEBUGSERVER, which can be set independently, to control
codesigning targets.

Currently, running cmake the first time in a clean directory, without
passing -DLLDB_CODESIGN_IDENTITY='', fails.  However, subsequent runs
succeed.  That's because LLDB_CODESIGN_IDENTITY gets added to the
CACHE after the initial test.  To fix that, the default value must be
set before it's tested.

Here's the error produced on the first run:

CMake Error at tools/lldb/tools/debugserver/source/CMakeLists.txt:215 (add_custom_command):
  No TARGET 'debugserver' has been created in this directory.

Differential Revision: https://reviews.llvm.org/D43432

llvm-svn: 325442
2018-02-17 19:17:21 +00:00
Vedant Kumar 361b5e1169 [cmake] Darwin: Copy in the system debugserver if needed
This makes the built debugger functional on Darwin when compiling
without code signing (as documented in docs/code-signing.txt).

llvm-svn: 325068
2018-02-13 23:05:46 +00:00
Aaron Smith 35cdfe2d1d Add CMAKE_CFG_INTDIR as part of the include path for the default test compiler.
Summary:
This is a small change towards running the LLDB unit tests on Windows (still WIP).

Builds that use make do not point to specific configurations. However, builds with multiple configurations such as Visual Studio on Windows need the configuration (release/debug/etc) as part of the path so the binaries produced by clang are placed in the correct directory for the configuration.

Reviewers: zturner, lldb-commits, labath

Reviewed By: labath

Subscribers: labath, mgorny, hintonda, llvm-commits

Differential Revision: https://reviews.llvm.org/D42990

llvm-svn: 324555
2018-02-08 02:13:48 +00:00
Pavel Labath 7e17fc5e09 Default to using in-tree clang for building test executables
Summary:
Using the in-tree clang should be the default test configuration as that
is the one compiler that we can be sure everyone has (better
reproducibility of test results). Also, it should hopefully reduce the
impact of pr35040.

This also reduces the number of settings which control the compiler
used. LLDB_TEST_C_COMPILER is used for C files and
LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
the in-tree clang.

Reviewers: zturner

Subscribers: mgorny, davide, lldb-commits

Differential Revision: https://reviews.llvm.org/D39215

llvm-svn: 316728
2017-10-27 02:24:04 +00:00
Chris Bieneman cc59060063 [CMake] Add LLDB_INCLUDE_TESTS variable
This behaves like the other *_INCLUDE_TESTS variables in CMake and is tied to LLVM_INCLUDE_TESTS so that if you're building in-tree and not building the LLVM tests, you also won't build the LLDB tests.

llvm-svn: 315120
2017-10-06 22:21:36 +00:00
Leonard Mosescu 63ed8c6c2e LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
Neither LLDB_CONFIGURATION_DEBUG nor LLDB_CONFIGURATION_RELEASE were ever set in the CMake LLDB project.

Also cleaned up a questionable #ifdef in SharingPtr.h, removing all the references to LLDB_CONFIGURATION_BUILD_AND_INTEGRATION in the process.

Differential Revision: https://reviews.llvm.org/D38552

llvm-svn: 314929
2017-10-04 20:23:56 +00:00
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
Deepak Panickal 9b35cf52d2 This creates a valid Python API for Windows, pending some issues. The changes included are -
- 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
2014-07-01 17:57:19 +00:00
Chandler Carruth 61220ef405 [cmake] When Python is disabled for LLDB, don't try to install the
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
2014-06-27 15:04:42 +00:00