maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/CMakeLists.txt

186 lines
6.9 KiB
CMake
Raw Normal View History

[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-06-01 04:21:44 +08:00
cmake_minimum_required(VERSION 3.4.3)
Standalone cmake build improvements (bug #23889) patch by Eugene Zelenko. llvm-svn: 242529
2015-07-17 23:50:48 +08:00
[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-28 00:04:26 +08:00
# Add path for custom modules
set(CMAKE_MODULE_PATH
${CMAKE_MODULE_PATH}
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
)
include(LLDBStandalone)
include(LLDBConfig)
include(AddLLDB)
Cmake build changes. Disables exception handling in LLDB, using appropriate compiler flags depending on the platform. This is consistent with the build of LLVM, should improve performance, and also removes a substantial number of warnings from the Windows build. See http://reviews.llvm.org/D3929 for more details. Change by Zachary Turner llvm-svn: 209752
2014-05-29 01:06:04 +08:00
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-05 04:23:56 +08:00
# Define the LLDB_CONFIGURATION_xxx matching the build type
if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
add_definitions( -DLLDB_CONFIGURATION_DEBUG )
else()
add_definitions( -DLLDB_CONFIGURATION_RELEASE )
endif()
Simple readline functionality for interactive python on linux. Differential Revision: http://reviews.llvm.org/D13268 llvm-svn: 249478
2015-10-07 06:21:08 +08:00
if (LLDB_DISABLE_LIBEDIT)
add_definitions( -DLLDB_DISABLE_LIBEDIT )
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-23 07:24:46 +08:00
else()
find_package(LibEdit REQUIRED)
Simple readline functionality for interactive python on linux. Differential Revision: http://reviews.llvm.org/D13268 llvm-svn: 249478
2015-10-07 06:21:08 +08:00
endif()
[CMake] Enable OS_LOG support on Darwin This gets CMake to match the Xcode project build llvm-svn: 309393
2017-07-28 23:39:50 +08:00
if(APPLE)
add_definitions(-DLLDB_USE_OS_LOG)
endif()
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(docs)
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 23:30:23 +08:00
if (NOT LLDB_DISABLE_PYTHON)
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 14:43:47 +08:00
add_subdirectory(scripts)
endif ()
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(source)
add_subdirectory(tools)
[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-07 06:21:36 +08:00
option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests."
${LLVM_INCLUDE_TESTS})
[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 08:05:51 +08:00
option(LLDB_TEST_USE_CUSTOM_C_COMPILER "Use the C compiler provided via LLDB_TEST_C_COMPILER for building test inferiors (instead of the just-built compiler). Defaults to OFF." OFF)
option(LLDB_TEST_USE_CUSTOM_CXX_COMPILER "Use the C++ compiler provided via LLDB_TEST_CXX_COMPILER for building test inferiors (instead of the just-built compiler). Defaults to OFF." OFF)
[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-07 06:21:36 +08:00
if(LLDB_INCLUDE_TESTS)
[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 21:59:25 +08:00
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-19 03:31:47 +08:00
# Set the path to the default lldb test executable. Make the path relative to
# LLVM_RUNTIME_OUTPUT_INTDIR: this will be correct even when LLVM and LLDB
# have separate binary directories.
[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 22:38:21 +08:00
set(LLDB_DEFAULT_TEST_EXECUTABLE "${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb${CMAKE_EXECUTABLE_SUFFIX}")
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-19 03:31:47 +08:00
# Set the paths to default llvm tools. Make these paths relative to the LLVM
# binary directory.
[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 21:59:25 +08:00
set(LLDB_DEFAULT_TEST_DSYMUTIL "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/dsymutil${CMAKE_EXECUTABLE_SUFFIX}")
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-19 03:31:47 +08:00
set(LLDB_DEFAULT_TEST_FILECHECK "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/FileCheck${CMAKE_EXECUTABLE_SUFFIX}")
[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 21:59:25 +08:00
[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 08:05:51 +08:00
if (NOT LLDB_TEST_USE_CUSTOM_C_COMPILER AND TARGET clang)
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 10:13:48 +08:00
set(LLDB_DEFAULT_TEST_C_COMPILER "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang${CMAKE_EXECUTABLE_SUFFIX}")
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 10:24:04 +08:00
else()
set(LLDB_DEFAULT_TEST_C_COMPILER "")
[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 08:05:51 +08:00
endif()
if (NOT LLDB_TEST_USE_CUSTOM_CXX_COMPILER AND TARGET clang)
set(LLDB_DEFAULT_TEST_CXX_COMPILER "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
else()
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 10:24:04 +08:00
set(LLDB_DEFAULT_TEST_CXX_COMPILER "")
endif()
[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 21:59:25 +08:00
set(LLDB_TEST_EXECUTABLE "${LLDB_DEFAULT_TEST_EXECUTABLE}" CACHE PATH "lldb executable used for testing")
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 10:24:04 +08:00
set(LLDB_TEST_C_COMPILER "${LLDB_DEFAULT_TEST_C_COMPILER}" CACHE PATH "C Compiler to use for building LLDB test inferiors")
set(LLDB_TEST_CXX_COMPILER "${LLDB_DEFAULT_TEST_CXX_COMPILER}" CACHE PATH "C++ Compiler to use for building LLDB test inferiors")
[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 21:59:25 +08:00
set(LLDB_TEST_DSYMUTIL "${LLDB_DEFAULT_TEST_DSYMUTIL}" CACHE PATH "dsymutil used for generating dSYM bundles")
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-19 03:31:47 +08:00
set(LLDB_TEST_FILECHECK "${LLDB_DEFAULT_TEST_FILECHECK}" CACHE PATH "FileCheck used for testing purposes")
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 10:24:04 +08:00
if (("${LLDB_TEST_C_COMPILER}" STREQUAL "") OR
("${LLDB_TEST_CXX_COMPILER}" STREQUAL ""))
message(FATAL_ERROR "LLDB test compilers not specified. Tests will not run")
endif()
[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-04 00:54:10 +08:00
set(LLDB_TEST_DEPS lldb)
# darwin-debug is an hard dependency for the testsuite.
if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
list(APPEND LLDB_TEST_DEPS darwin-debug)
endif()
if(TARGET lldb-server)
list(APPEND LLDB_TEST_DEPS lldb-server)
endif()
if(TARGET debugserver)
[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 20:46:30 +08:00
list(APPEND LLDB_TEST_DEPS debugserver)
[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-04 00:54:10 +08:00
endif()
if(TARGET lldb-mi)
list(APPEND LLDB_TEST_DEPS lldb-mi)
endif()
if(NOT LLDB_BUILT_STANDALONE)
[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 21:59:25 +08:00
list(APPEND LLDB_TEST_DEPS yaml2obj)
[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-04 00:54:10 +08:00
endif()
if(TARGET liblldb)
list(APPEND LLDB_TEST_DEPS liblldb)
endif()
[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-10 00:25:31 +08:00
# Add dependencies if we test with the in-tree clang.
# This works with standalone builds as they import the clang target.
[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-04 00:54:10 +08:00
if(TARGET clang)
list(APPEND LLDB_TEST_DEPS clang)
[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-19 04:59:23 +08:00
if(APPLE)
[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-10 00:25:31 +08:00
# If we build clang, we should build libcxx.
# FIXME: Standalone builds should import the cxx target as well.
if(LLDB_BUILT_STANDALONE)
# For now check that the include directory exists.
[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-10 00:25:37 +08:00
set(cxx_dir "${LLVM_BINARY_DIR}/include/c++")
[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-10 00:25:31 +08:00
if(NOT EXISTS ${cxx_dir})
message(WARNING "LLDB test suite requires libc++ in llvm/projects/libcxx or an existing build symlinked to ${cxx_dir}")
endif()
else()
list(APPEND LLDB_TEST_DEPS cxx)
endif()
[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-19 04:59:23 +08:00
endif()
[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-04 00:54:10 +08:00
endif()
[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 21:59:25 +08:00
if(TARGET dsymutil)
list(APPEND LLDB_TEST_DEPS dsymutil)
endif()
[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-07 06:21:36 +08:00
add_subdirectory(test)
add_subdirectory(unittests)
add_subdirectory(lit)
[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-04 00:54:10 +08:00
add_subdirectory(utils/lldb-dotest)
[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-07 06:21:36 +08:00
endif()
[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-18 06:20:29 +08:00
[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 13:00:22 +08:00
if (NOT LLDB_DISABLE_PYTHON)
[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 20:46:50 +08:00
if(NOT LLDB_BUILD_FRAMEWORK)
set(use_python_wrapper_from_src_dir -m)
endif()
if(LLDB_USE_SYSTEM_SIX)
set(use_six_py_from_system --useSystemSix)
endif()
[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 20:47:02 +08:00
get_target_property(lldb_scripts_dir swig_wrapper BINARY_DIR)
get_target_property(liblldb_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
[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 20:46:50 +08:00
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-17 00:38:25 +08:00
# Add a Post-Build Event to copy over Python files and create the symlink
# to liblldb.so for the Python API(hardlink on Windows)
add_custom_target(finish_swig ALL
COMMAND
[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 20:47:02 +08:00
${PYTHON_EXECUTABLE} ${LLDB_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
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-17 00:38:25 +08:00
--srcRoot=${LLDB_SOURCE_DIR}
[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 20:47:02 +08:00
--targetDir=${liblldb_build_dir}
--cfgBldDir=${lldb_scripts_dir}
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-17 00:38:25 +08:00
--prefix=${CMAKE_BINARY_DIR}
--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}
--lldbLibDir=lib${LLVM_LIBDIR_SUFFIX}
[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 20:46:50 +08:00
${use_python_wrapper_from_src_dir}
${use_six_py_from_system}
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-17 00:38:25 +08:00
VERBATIM
[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 20:47:02 +08:00
DEPENDS ${LLDB_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
DEPENDS ${lldb_scripts_dir}/lldb.py
[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-18 06:20:29 +08:00
COMMENT "Python script sym-linking LLDB Python API")
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-19 02:27:16 +08:00
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 09:28:51 +08:00
if (TARGET readline)
[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 20:46:50 +08:00
set(readline_dep readline)
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 09:28:51 +08:00
endif()
[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 20:46:50 +08:00
add_dependencies(finish_swig swig_wrapper liblldb lldb-argdumper ${readline_dep})
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 09:28:51 +08:00
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 23:34:06 +08:00
# Ensure we do the python post-build step when building lldb.
add_dependencies(lldb finish_swig)
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 15:55:44 +08:00
[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 20:46:50 +08:00
if(LLDB_BUILD_FRAMEWORK)
add_dependencies(lldb-framework finish_swig)
[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-16 02:19:10 +08:00
endif()
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 15:55:44 +08:00
# Add a Post-Build Event to copy the custom Python DLL to the lldb binaries dir so that Windows can find it when launching
# lldb.exe or any other executables that were linked with liblldb.
if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
# When using the Visual Studio CMake generator the lldb binaries end up in Release/bin, Debug/bin etc.
file(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin" LLDB_BIN_DIR)
file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
add_custom_command(
TARGET finish_swig
POST_BUILD
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-17 00:38:25 +08:00
COMMAND ${CMAKE_COMMAND} -E copy ${PYTHON_DLL_NATIVE_PATH} ${LLDB_BIN_DIR} VERBATIM
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 15:55:44 +08:00
COMMENT "Copying Python DLL to LLDB binaries directory.")
endif ()
[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-18 06:20:29 +08:00
endif ()