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

235 lines
8.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
Set cmake policy CMP0075 to NEW Summary: The policy is about cmake_include_files ignoring CMAKE_REQUIRED_LIBRARIES in the OLD behavior. Llvm already sets this policy to NEW, but that is overridden by our cmake_minimum_required command. This makes our cmake policy setup consistent with the llvm build files and avoids a warning when using newer versions of cmake. Reviewers: sgraenitz, xiaobai Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58279 llvm-svn: 354251
2019-02-18 18:09:29 +08:00
if(POLICY CMP0075)
cmake_policy(SET CMP0075 NEW)
endif()
Added a dot at the end of comment Summary: to test SVN commit access with a simple change. Reviewers: jankratochvil Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62243 llvm-svn: 361383
2019-05-22 21:23:15 +08:00
# Add path for custom modules.
[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
set(CMAKE_MODULE_PATH
${CMAKE_MODULE_PATH}
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
)
[CMake] Move standalone check so we don't have to reconfigure LLDB By moving the standalone check into the main CMake file, the whole file is ignored in a regular (non-standalone) build. This means that you can make changes to LLDBStandalone.cmake without having to reconfigure a build in a different directory. This matters when you share one source repository with different build directories (e.g. release-assert, debug, standalone). Differential revision: https://reviews.llvm.org/D64824 llvm-svn: 366346
2019-07-18 00:47:02 +08:00
# If we are not building as part of LLVM, build LLDB as a standalone project,
# using LLVM as an external library.
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
[CMake] Move project() call to main CMake file Summary: The main CMake file don't have a project() call. In this case, cmake will run a dummy project(Project ) at the very beginning. Even before cmake_minimum_required. And a series of compiler detections will be triggered. This is problematic if we depends on some policy to be set. E.g. CMP0056. try_compile will fail before we have a chance to do anything. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65362 llvm-svn: 367273
2019-07-30 07:09:31 +08:00
project(lldb)
[CMake] Move standalone check so we don't have to reconfigure LLDB By moving the standalone check into the main CMake file, the whole file is ignored in a regular (non-standalone) build. This means that you can make changes to LLDBStandalone.cmake without having to reconfigure a build in a different directory. This matters when you share one source repository with different build directories (e.g. release-assert, debug, standalone). Differential revision: https://reviews.llvm.org/D64824 llvm-svn: 366346
2019-07-18 00:47:02 +08:00
include(LLDBStandalone)
endif()
[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
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
Added a dot at the end of comment Summary: to test SVN commit access with a simple change. Reviewers: jankratochvil Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62243 llvm-svn: 361383
2019-05-22 21:23:15 +08:00
# Define the LLDB_CONFIGURATION_xxx matching the build type.
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
if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
add_definitions( -DLLDB_CONFIGURATION_DEBUG )
else()
add_definitions( -DLLDB_CONFIGURATION_RELEASE )
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()
Define _ENABLE_EXTENDED_ALIGNED_STORAGE on Windows. Apparently there are multiple places where MSVC complains about instantiations with extended aligment. I think it's better to define `_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message. I don't have access to a Windows machine so this is all speculative. llvm-svn: 353778
2019-02-12 08:30:21 +08:00
if (WIN32)
add_definitions(-D_ENABLE_EXTENDED_ALIGNED_STORAGE)
endif()
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 ()
[lldb] Let table gen create command option initializers. Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908
2019-07-12 23:30:55 +08:00
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE)
set(LLVM_USE_HOST_TOOLS ON)
include(CrossCompile)
[cmake] Update NATIVE build variables to account for standalone changes Summary: LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64959 llvm-svn: 366513
2019-07-19 07:40:23 +08:00
if (NOT NATIVE_LLVM_DIR OR NOT NATIVE_Clang_DIR)
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
message(FATAL_ERROR
[cmake] Update NATIVE build variables to account for standalone changes Summary: LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64959 llvm-svn: 366513
2019-07-19 07:40:23 +08:00
"Crosscompiling standalone requires the variables NATIVE_{CLANG,LLVM}_DIR
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
for building the native lldb-tblgen used during the build process.")
endif()
llvm_create_cross_target(lldb NATIVE "" Release
[cmake] Update NATIVE build variables to account for standalone changes Summary: LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64959 llvm-svn: 366513
2019-07-19 07:40:23 +08:00
-DLLVM_DIR=${NATIVE_LLVM_DIR}
-DClang_DIR=${NATIVE_Clang_DIR})
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
endif()
[TableGen] Move interpreter properties into a separate file (NFC) With the plugins having their own tablgen file, it makes sense to split off the interpreter properties as well. llvm-svn: 367138
2019-07-27 02:14:04 +08:00
# TableGen
[lldb] Let table gen create command option initializers. Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908
2019-07-12 23:30:55 +08:00
add_subdirectory(utils/TableGen)
[TableGen] Move interpreter properties into a separate file (NFC) With the plugins having their own tablgen file, it makes sense to split off the interpreter properties as well. llvm-svn: 367138
2019-07-27 02:14:04 +08:00
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(source)
add_subdirectory(tools)
[Docs] Generate the python reference without building all of LLDB As discussed on the mailing list, we should be able to generate the Python reference without building all of LLDB. To make that possible I create a dummy python package, which is then parsed by epydoc. The latter will complain that it couldn't import lldb, but that doesn't matter as far as generation of the docs is concerned. Differential revision: https://reviews.llvm.org/D61216 llvm-svn: 359465
2019-04-30 00:29:10 +08:00
add_subdirectory(docs)
[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
[CMake] Include tests by default also in standalone builds In-tree builds include tests by default. Standalone builds should behave the same. llvm-svn: 350945
2019-01-12 02:11:04 +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] Remove dead code and outdated comments Summary: All of these changes are NOPs. Reviewers: stella.stamenova, labath, JDevlieghere Reviewed By: stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56609 llvm-svn: 350937
2019-01-12 01:51:33 +08:00
# Set the path to the default lldb test executable.
[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
[CMake] Remove dead code and outdated comments Summary: All of these changes are NOPs. Reviewers: stella.stamenova, labath, JDevlieghere Reviewed By: stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56609 llvm-svn: 350937
2019-01-12 01:51:33 +08:00
# Set the paths to default llvm tools.
[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()
[Cmake] Add missing dependency for running tests. This is needed now that we marked lldb-test as EXCLUDE_ALL, to make sure `ninja lldb-test-deps` doesn't fail. llvm-svn: 358625
2019-04-18 07:43:01 +08:00
# lldb-test is an hard dependency for the testsuite.
list(APPEND LLDB_TEST_DEPS lldb-test)
[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 lldb-server)
list(APPEND LLDB_TEST_DEPS lldb-server)
endif()
Add lldb-vscode as a dependency of lldb tests. Summary: In the current state, 'ninja check-lldb' runs the lldb-vscode tests, but it won't rebuild lldb-vscode if any of its sources has changed. This is very confusing when you fix something and the tests keep failing, or vice versa. Reviewers: clayborg Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59828 llvm-svn: 357016
2019-03-27 02:36:44 +08:00
if(TARGET lldb-vscode)
list(APPEND LLDB_TEST_DEPS lldb-vscode)
endif()
[lldb-instr] Make lldb-instr a test dependency llvm-svn: 353444
2019-02-08 02:41:59 +08:00
if(TARGET lldb-instr)
list(APPEND LLDB_TEST_DEPS lldb-instr)
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
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()
[CMake] Add error to clarify that lldb requires libcxx Summary: This adds a specific error message to clarify that lldb requires libcxx when built together with clang on macOS. In addition, the lldb building docs are also updated. Fixes https://bugs.llvm.org/show_bug.cgi?id=41866 Reviewers: sgraenitz, JDevlieghere, EricWF Reviewed By: sgraenitz Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61877 llvm-svn: 360756
2019-05-15 16:59:02 +08:00
# We require libcxx for the test suite, so if we aren't building it,
# try to provide a helpful error about how to resolve the situation.
if(NOT TARGET cxx)
if(LLVM_ENABLE_PROJECTS STREQUAL "")
# If `LLVM_ENABLE_PROJECTS` is not being used (implying that we are
# using the old layout), suggest checking it out.
message(FATAL_ERROR
"LLDB test suite requires libc++, but it is currently disabled. "
"Please checkout `libcxx` in `llvm/projects` or disable tests "
"via `LLDB_INCLUDE_TESTS=OFF`.")
else()
# If `LLVM_ENABLE_PROJECTS` is being used, suggest adding it.
message(FATAL_ERROR
"LLDB test suite requires libc++, but it is currently disabled. "
"Please add `libcxx` to `LLVM_ENABLE_PROJECTS` or disable tests "
"via `LLDB_INCLUDE_TESTS=OFF`.")
endif()
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
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] LLDB.framework tools handling Summary: Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach. No function change otherwise. This is a reduced follow-up from the proposal in D61952. Reviewers: xiaobai, compnerd, JDevlieghere Reviewed By: JDevlieghere Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D62472 llvm-svn: 361946
2019-05-29 19:26:06 +08:00
if(TARGET lldb-framework)
list(APPEND LLDB_TEST_DEPS lldb-framework)
endif()
[CMake] Fix subtle CMake bug CMake specifies that the DEPENDS field of add_custom_target is for files and output of add_custom_command. In order to add a target dependency, add_dependencies should be used. llvm-svn: 359490
2019-04-30 03:44:43 +08:00
add_custom_target(lldb-test-deps)
add_dependencies(lldb-test-deps ${LLDB_TEST_DEPS})
[CMake] Folder structure for generated Xcode project to cover more targets llvm-svn: 361799
2019-05-28 17:29:05 +08:00
set_target_properties(lldb-test-deps PROPERTIES FOLDER "lldb misc")
[CMake] Fix lldb-test-depends target The lldb-test-depends target was using the old CMake variable name LLDB_TEST_DEPENDS instead of LLDB_TEST_DEPS. This patch moves the target definition and makes it use the correct one. llvm-svn: 351489
2019-01-18 06:25:20 +08:00
[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)
[lldb] [lit] Add feature flags for native CPU features Add a new lit-cpuid tool that detects CPU features used by some of the tests, and use it to populate available_features in lit. For now, this means that the test for MM/XMM register read will be run only when the host CPU support SSE instruction set. However, this is going to make it possible to introduce additional tests relying on AVX. Differential Revision: https://reviews.llvm.org/D61073 llvm-svn: 359303
2019-04-26 21:21:46 +08:00
add_subdirectory(utils/lit-cpuid)
[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
Added a dot at the end of comment Summary: to test SVN commit access with a simple change. Reviewers: jankratochvil Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62243 llvm-svn: 361383
2019-05-22 21:23:15 +08:00
# to liblldb.so for the Python API(hardlink on Windows).
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_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] Remove check for the readline target. This was introduced when we were building a custom readline Python module on Linux [1]. Now that the readline target doesn't exist anymore, it's safe to remove this dependency. This fixes https://llvm.org/PR25136 [1] https://reviews.llvm.org/D13268 llvm-svn: 367956
2019-08-06 07:54:13 +08:00
add_dependencies(finish_swig swig_wrapper liblldb lldb-argdumper)
[CMake] Folder structure for generated Xcode project to cover more targets llvm-svn: 361799
2019-05-28 17:29:05 +08:00
set_target_properties(finish_swig swig_wrapper PROPERTIES FOLDER "lldb misc")
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
# 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 ()
[CMake] Distribution builds for LLDB standalone Summary: Enable `distribution` and `install-distribution` targets in LLDB standalone and pre-populate the cache accordingly on macOS. Documentation for distribution builds is here: https://llvm.org/docs/BuildingADistribution.html Reviewers: xiaobai, mgorny, JDevlieghere, davide, compnerd Reviewed By: xiaobai, JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64399 llvm-svn: 365616
2019-07-10 19:09:11 +08:00
[CMake] Polish folders in generated Xcode project Summary: Group plugins by subfolder. Move liblldb-resource-headers to `lldb misc`. Avoid install-distribution related targets in IDE-enabled builds. Reviewers: jingham, mib, stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64865 llvm-svn: 366459
2019-07-19 00:44:45 +08:00
if(LLDB_BUILT_STANDALONE AND NOT LLVM_ENABLE_IDE)
[CMake] Distribution builds for LLDB standalone Summary: Enable `distribution` and `install-distribution` targets in LLDB standalone and pre-populate the cache accordingly on macOS. Documentation for distribution builds is here: https://llvm.org/docs/BuildingADistribution.html Reviewers: xiaobai, mgorny, JDevlieghere, davide, compnerd Reviewed By: xiaobai, JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64399 llvm-svn: 365616
2019-07-10 19:09:11 +08:00
llvm_distribution_add_targets()
endif()