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

220 lines
7.7 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()
[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 19:55:00 +08:00
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
Fix Android build. llvm-svn: 249486
2015-10-07 08:01:06 +08:00
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
set(LLDB_DEFAULT_DISABLE_LIBEDIT 0)
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
# We need libedit support to go down both the source and
# the scripts directories.
set(LLDB_DISABLE_LIBEDIT ${LLDB_DEFAULT_DISABLE_LIBEDIT} CACHE BOOL "Disables the use of editline.")
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()
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
# lldb-suite is a dummy target that encompasses all the necessary tools and
# libraries for building a fully-functioning liblldb.
add_custom_target(lldb-suite)
option(LLDB_BUILD_FRAMEWORK "Build the Darwin LLDB.framework" Off)
[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 20:30:27 +08:00
if(LLDB_BUILD_FRAMEWORK)
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
if (CMAKE_VERSION VERSION_LESS 3.7)
message(FATAL_ERROR "LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7")
endif()
if (NOT APPLE)
message(FATAL_ERROR "LLDB.framework can only be generated when targeting Apple platforms")
endif()
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 10:59:30 +08:00
# These are used to fill out LLDB-Info.plist. These are relevant when building
# the framework, and must be defined before building liblldb.
set(PRODUCT_NAME "LLDB")
set(EXECUTABLE_NAME "LLDB")
set(CURRENT_PROJECT_VERSION "360.99.0")
[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 20:30:27 +08:00
set(LLDB_FRAMEWORK_DIR
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_FRAMEWORK_INSTALL_DIR})
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)
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 08:20:24 +08:00
if(LLDB_USE_SYSTEM_SIX)
set(SIX_EXTRA_ARGS "--useSystemSix")
endif()
[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-22 05:02:16 +08:00
set(LLDB_PYTHON_TARGET_DIR ${LLDB_BINARY_DIR}/scripts)
[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-26 04:30:35 +08:00
set(LLDB_WRAP_PYTHON ${LLDB_BINARY_DIR}/scripts/LLDBWrapPython.cpp)
[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-22 05:02:16 +08:00
if(LLDB_BUILD_FRAMEWORK)
[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 20:30:27 +08:00
set(LLDB_PYTHON_TARGET_DIR ${LLDB_FRAMEWORK_DIR})
[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-26 04:30:35 +08:00
set(LLDB_WRAP_PYTHON ${LLDB_PYTHON_TARGET_DIR}/LLDBWrapPython.cpp)
[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-22 05:02:16 +08:00
else()
# Don't set -m when building the framework.
set(FINISH_EXTRA_ARGS "-m")
endif()
[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-26 04:30:35 +08:00
[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-22 05:02:16 +08:00
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 ()
[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-14 07:05:46 +08:00
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
[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 22:34:32 +08:00
# The difference between the following two paths is significant. The path to
# LLDB will point to LLDB's binary directory, while the other will point to
# LLVM's binary directory in case the two differ.
[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}")
[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}")
[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")
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)
if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
list(APPEND LLDB_TEST_DEPS debugserver)
endif()
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()
if(TARGET clang)
list(APPEND LLDB_TEST_DEPS clang)
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
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
if (LLDB_BUILD_FRAMEWORK)
add_custom_target(lldb-framework)
include(LLDBFramework)
add_dependencies(lldb-suite lldb-framework)
endif()
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 22:23:31 +08:00
add_dependencies(lldb-suite liblldb)
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] 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)
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
${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
--srcRoot=${LLDB_SOURCE_DIR}
--targetDir=${LLDB_PYTHON_TARGET_DIR}
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-05 07:47:36 +08:00
--cfgBldDir=${LLDB_PYTHON_TARGET_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}
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 08:20:24 +08:00
${SIX_EXTRA_ARGS}
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
${FINISH_EXTRA_ARGS}
VERBATIM
[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
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
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-05 07:47:36 +08:00
DEPENDS ${LLDB_PYTHON_TARGET_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
# We depend on liblldb and lldb-argdumper being built before we can do this step.
add_dependencies(finish_swig lldb-suite)
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
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 we build the readline module, we depend on that happening
# first.
if (TARGET readline)
add_dependencies(finish_swig readline)
endif()
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
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
if (LLDB_BUILD_FRAMEWORK)
# The target to install libLLDB needs to depend on finish_swig so that the
[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
# framework build properly copies over the Python files.
add_dependencies(install-liblldb finish_swig)
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 ()