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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

318 lines
12 KiB
CMake
Raw Normal View History

[cmake] Add a big warning about a libstdc++ issue Summary: Recent increase in the usage of std::weak_ptr has caused us to rediscover an issue in libstdc++ versions prior to 4.9 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656>, which make this class unusable without exceptions in the presence of multiple threads. It's virtualy impossible to work around this issue without implementing our own shared_ptr/weak_ptr substitutes, which does not seem like a good idea. Therefore, I am adding a big CMake warning which warns you about this issue if you're attempting a to do a build which is suceptible to this problem and suggests possible alternatives. Right now, nothing spectacular will happen if you ignore this warning (all the crashes I have seen occur during process shutdown), but there's no guarantee the situation will not change in the future. Reviewers: tberghammer, tfiala, nitesh.jain, omjavaid, emaste, krytarowski Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20671 llvm-svn: 270854
2016-05-26 23:16:11 +08:00
include(CheckCXXSymbolExists)
[cmake] Move LLDB_DISABLE_LIBEDIT handling code into a central place This was previously scattered between the main CMakeLists.txt file and LLDBGenerateConfig.cmake and LLDBConfig.cmake. This caused the some of the code to be executed in incorrect order. Specifically, the check for el_winsertstr was done before libedit_LIBRARIES was computed, and so it always failed on the first run. Moving it the two checks to a central place makes sure this doesn't happen again and improves the overall readability. llvm-svn: 355103
2019-03-01 00:04:54 +08:00
include(CheckTypeSize)
[cmake] Add a big warning about a libstdc++ issue Summary: Recent increase in the usage of std::weak_ptr has caused us to rediscover an issue in libstdc++ versions prior to 4.9 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656>, which make this class unusable without exceptions in the presence of multiple threads. It's virtualy impossible to work around this issue without implementing our own shared_ptr/weak_ptr substitutes, which does not seem like a good idea. Therefore, I am adding a big CMake warning which warns you about this issue if you're attempting a to do a build which is suceptible to this problem and suggests possible alternatives. Right now, nothing spectacular will happen if you ignore this warning (all the crashes I have seen occur during process shutdown), but there's no guarantee the situation will not change in the future. Reviewers: tberghammer, tfiala, nitesh.jain, omjavaid, emaste, krytarowski Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20671 llvm-svn: 270854
2016-05-26 23:16:11 +08:00
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
set(LLDB_PROJECT_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_SOURCE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/source")
set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
[CMake] Revised LLDB.framework builds Summary: Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements. Options: * `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree) * `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree * `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`) * `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets) Other changes: * clean up `add_lldb_executable()` * include `LLDBFramework.cmake` from `source/API/CMakeLists.txt` * use `*.plist.in` files, which are typical for CMake and independent from Xcode * add clang headers to the framework bundle Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath Reviewed By: aprantl Subscribers: friss, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55328 llvm-svn: 350391
2019-01-04 20:46:50 +08:00
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR
"In-source builds are not allowed. CMake would overwrite the makefiles "
"distributed with LLDB. Please create a directory and run cmake from "
"there, passing the path to this source directory as the last argument. "
"This process created the file `CMakeCache.txt' and the directory "
"`CMakeFiles'. Please delete them.")
endif()
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
set(LLDB_LINKER_SUPPORTS_GROUPS OFF)
if (LLVM_COMPILER_IS_GCC_COMPATIBLE AND NOT "${CMAKE_SYSTEM_NAME}" MATCHES "Darwin")
# The Darwin linker doesn't understand --start-group/--end-group.
set(LLDB_LINKER_SUPPORTS_GROUPS ON)
Revert "[lldb/CMake] Change how we deal with optional dependencies" This is failing on both the Windows and Debian bot.
2019-12-21 07:34:51 +08:00
endif()
[lldb/CMake] Change how we deal with optional dependencies Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-19 03:19:06 +08:00
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
macro(add_optional_dependency variable description package found)
[lldb/CMake] Use LLDB's autodetection logic for libxml2 Libxml2 is already an optional dependency. It should use the same infrastructure as the other dependencies. Differential revision: https://reviews.llvm.org/D72290
2020-01-09 01:03:40 +08:00
cmake_parse_arguments(ARG
""
"VERSION"
""
${ARGN})
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
set(${variable} "Auto" CACHE STRING "${description} On, Off or Auto (default)")
string(TOUPPER "${${variable}}" ${variable})
if("${${variable}}" STREQUAL "AUTO")
[lldb/CMake] Don't use return() from macro() > A macro is executed as if the macro body were pasted in place of the > calling statement. This has the consequence that a return() in a macro > body does not just terminate execution of the macro After converting from a function() to a macro(), the return() became invalid. This modifies the control flow to elude the return.
2019-12-21 12:53:33 +08:00
set(find_package TRUE)
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
set(maybe_required)
elseif(${${variable}})
[lldb/CMake] Don't use return() from macro() > A macro is executed as if the macro body were pasted in place of the > calling statement. This has the consequence that a return() in a macro > body does not just terminate execution of the macro After converting from a function() to a macro(), the return() became invalid. This modifies the control flow to elude the return.
2019-12-21 12:53:33 +08:00
set(find_package TRUE)
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
set(maybe_required REQUIRED)
else()
[lldb/CMake] Always set a value for find_package when finding optional dependencies Because this is a macro, previous values of `find_package` persist between calls. This means that if it is set to TRUE on any run, all subsequent runs will have find_package set to TRUE regardles of whether or not they should be.
2019-12-24 05:37:56 +08:00
set(find_package FALSE)
[lldb/CMake] Print whether an optional dependency was enabled. Use a status message to convey whether an optional dependency was found or not. With the auto-detection code it's not longer as simple as checking the CMake cache.
2020-01-03 05:36:05 +08:00
set(${variable} FALSE)
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
endif()
[lldb/CMake] Don't use return() from macro() > A macro is executed as if the macro body were pasted in place of the > calling statement. This has the consequence that a return() in a macro > body does not just terminate execution of the macro After converting from a function() to a macro(), the return() became invalid. This modifies the control flow to elude the return.
2019-12-21 12:53:33 +08:00
if(${find_package})
[lldb/CMake] Use LLDB's autodetection logic for libxml2 Libxml2 is already an optional dependency. It should use the same infrastructure as the other dependencies. Differential revision: https://reviews.llvm.org/D72290
2020-01-09 01:03:40 +08:00
find_package(${package} ${ARG_VERSION} ${maybe_required})
[lldb/CMake] Don't use return() from macro() > A macro is executed as if the macro body were pasted in place of the > calling statement. This has the consequence that a return() in a macro > body does not just terminate execution of the macro After converting from a function() to a macro(), the return() became invalid. This modifies the control flow to elude the return.
2019-12-21 12:53:33 +08:00
set(${variable} "${${found}}")
endif()
[lldb/CMake] Print whether an optional dependency was enabled. Use a status message to convey whether an optional dependency was found or not. With the auto-detection code it's not longer as simple as checking the CMake cache.
2020-01-03 05:36:05 +08:00
message(STATUS "${description}: ${${variable}}")
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
endmacro()
[lldb/CMake] Print whether an optional dependency was enabled. Use a status message to convey whether an optional dependency was found or not. With the auto-detection code it's not longer as simple as checking the CMake cache.
2020-01-03 05:36:05 +08:00
add_optional_dependency(LLDB_ENABLE_LIBEDIT "Enable editline support in LLDB" LibEdit LibEdit_FOUND)
add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses support in LLDB" CursesAndPanel CURSESANDPANEL_FOUND)
add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in LLDB" LibLZMA LIBLZMA_FOUND)
[lldb/CMake] Only auto-enable Lua when SWIG is found Just like Python, Lua should only be auto-enabled if SWIG is found as well. This moves the logic of finding SWIG and Lua as a whole into a new CMake package.
2020-01-09 06:01:57 +08:00
add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB" LuaAndSwig LUAANDSWIG_FOUND)
[lldb] Get rid of helper CMake variables for Python This patch is a big sed to rename the following variables: s/PYTHON_LIBRARIES/Python3_LIBRARIES/g s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g s/PYTHON_RPATH/Python3_RPATH/g I've also renamed the CMake module to better express its purpose and for consistency with FindLuaAndSwig. Differential revision: https://reviews.llvm.org/D85976
2020-08-17 23:47:52 +08:00
add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support in LLDB" PythonAndSwig PYTHONANDSWIG_FOUND)
[lldb/CMake] Use LLDB's autodetection logic for libxml2 Libxml2 is already an optional dependency. It should use the same infrastructure as the other dependencies. Differential revision: https://reviews.llvm.org/D72290
2020-01-09 01:03:40 +08:00
add_optional_dependency(LLDB_ENABLE_LIBXML2 "Enable Libxml 2 support in LLDB" LibXml2 LIBXML2_FOUND VERSION 2.8)
[lldb/CMake] Change how we deal with optional dependencies Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-19 03:19:06 +08:00
[CMake] Aggregate options for LLDB in LLDBConfig.cmake Summary: In preparation for LLDB.framework changes, collect options for LLDB in LLDBConfig.cmake (used for both, standalone and in-tree builds of LLDB). Reviewers: JDevlieghere, aprantl, xiaobai Reviewed By: aprantl Subscribers: srhines, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55317 llvm-svn: 350389
2019-01-04 20:46:34 +08:00
option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install a copy of it" OFF)
option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if available" ON)
option(LLDB_BUILD_FRAMEWORK "Build LLDB.framework (Darwin only)" OFF)
[CMake] Revised RPATH handling Summary: If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling. * In the build-tree, tools use the absolute path to the framework's actual output location. * In the install-tree, tools get a list of RPATHs to look for the framework when deployed. `LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree. If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree). If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree. For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks". Reviewers: xiaobai, JDevlieghere, aprantl, clayborg Reviewed By: JDevlieghere Subscribers: ki.stfu, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55330 llvm-svn: 350392
2019-01-04 20:46:57 +08:00
option(LLDB_NO_INSTALL_DEFAULT_RPATH "Disable default RPATH settings in binaries" OFF)
[CMake] Always build debugserver on Darwin and allow tests to use the system's one Summary: We can always build debugserver, but we can't always sign it to be useable for testing. `LLDB_USE_SYSTEM_DEBUGSERVER` should only tell whether or not the system debugserver should be used for testing. The old behavior complicated the logic around debugserver a lot. The new logic sorts out most of it. Please note that this patch is in early stage and needs some more testing. It should not affect platfroms other than Darwin. It builds on Davide's approach to validate the code-signing identity at configuration time. What do you think? Reviewers: xiaobai, JDevlieghere, davide, compnerd, friss, labath, mgorny, jasonmolenda Reviewed By: JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64806 llvm-svn: 366433
2019-07-18 21:30:37 +08:00
option(LLDB_USE_SYSTEM_DEBUGSERVER "Use the system's debugserver for testing (Darwin only)." OFF)
[cmake] Add an option to skip stripping before install The swift build system has support for cross-compiling, installing, and generating symbols for lldb. As the swift symbol-generation step occurs after installation, we need to disable stripping during the install.
2019-11-05 09:00:23 +08:00
option(LLDB_SKIP_STRIP "Whether to skip stripping of binaries when installing lldb." OFF)
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
[LLDB] Always remove debugserver from LLVM_DISTRIBUTION_COMPONENTS Centralize the logic to remove debugserver from LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is enabled. Now this happens regardless of whether the tests are enabled.
2019-11-13 04:57:00 +08:00
if (LLDB_USE_SYSTEM_DEBUGSERVER)
# The custom target for the system debugserver has no install target, so we
# need to remove it from the LLVM_DISTRIBUTION_COMPONENTS list.
if (LLVM_DISTRIBUTION_COMPONENTS)
list(REMOVE_ITEM LLVM_DISTRIBUTION_COMPONENTS debugserver)
set(LLVM_DISTRIBUTION_COMPONENTS ${LLVM_DISTRIBUTION_COMPONENTS} CACHE STRING "" FORCE)
endif()
endif()
[CMake] Aggregate options for LLDB in LLDBConfig.cmake Summary: In preparation for LLDB.framework changes, collect options for LLDB in LLDBConfig.cmake (used for both, standalone and in-tree builds of LLDB). Reviewers: JDevlieghere, aprantl, xiaobai Reviewed By: aprantl Subscribers: srhines, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55317 llvm-svn: 350389
2019-01-04 20:46:34 +08:00
if(LLDB_BUILD_FRAMEWORK)
if(NOT APPLE)
message(FATAL_ERROR "LLDB.framework can only be generated when targeting Apple platforms")
endif()
[CMake] Revised LLDB.framework builds Summary: Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements. Options: * `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree) * `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree * `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`) * `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets) Other changes: * clean up `add_lldb_executable()` * include `LLDBFramework.cmake` from `source/API/CMakeLists.txt` * use `*.plist.in` files, which are typical for CMake and independent from Xcode * add clang headers to the framework bundle Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath Reviewed By: aprantl Subscribers: friss, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55328 llvm-svn: 350391
2019-01-04 20:46:50 +08:00
set(LLDB_FRAMEWORK_VERSION A CACHE STRING "LLDB.framework version (default is A)")
set(LLDB_FRAMEWORK_BUILD_DIR bin CACHE STRING "Output directory for LLDB.framework")
set(LLDB_FRAMEWORK_INSTALL_DIR Library/Frameworks CACHE STRING "Install directory for LLDB.framework")
[lldb] Record framework build path and use it everywhere This avoids config time dependencies on liblldb. And enables other refactoring.
2019-10-31 01:33:05 +08:00
get_filename_component(LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR ${LLDB_FRAMEWORK_BUILD_DIR} ABSOLUTE
BASE_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR})
[CMake] `install-distribution` for LLDB on Darwin Summary: There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time. LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally. Please let me know what you think, while I run a few more tests and add remarks+documentation. Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny Reviewed By: xiaobai, JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64408 llvm-svn: 365617
2019-07-10 19:09:29 +08:00
# Essentially, emit the framework's dSYM outside of the framework directory.
set(LLDB_DEBUGINFO_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin CACHE STRING
"Directory to emit dSYM files stripped from executables and libraries (Darwin Only)")
[CMake] Aggregate options for LLDB in LLDBConfig.cmake Summary: In preparation for LLDB.framework changes, collect options for LLDB in LLDBConfig.cmake (used for both, standalone and in-tree builds of LLDB). Reviewers: JDevlieghere, aprantl, xiaobai Reviewed By: aprantl Subscribers: srhines, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55317 llvm-svn: 350389
2019-01-04 20:46:34 +08:00
endif()
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
[lldb][CMake] Generating Xcode projects Summary: Print a warning if the wrong cache script is used when generating a Xcode project, because it's too easy to confuse with Apple-lldb-macOS.cmake ``` When building with Xcode, we recommend using the corresponding cache script. If this was a mistake, clean your build directory and re-run CMake with: -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject ``` Also set the generator inside the cache script. Reviewers: JDevlieghere, jingham, clayborg Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368066
2019-08-07 01:21:34 +08:00
if(APPLE AND CMAKE_GENERATOR STREQUAL Xcode)
if(NOT LLDB_EXPLICIT_XCODE_CACHE_USED)
message(WARNING
"When building with Xcode, we recommend using the corresponding cache script. "
[lldb][NFC] Fix typo in 368066 Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368143
2019-08-07 18:03:11 +08:00
"If this was a mistake, clean your build directory and re-run CMake with:\n"
[lldb][CMake] Generating Xcode projects Summary: Print a warning if the wrong cache script is used when generating a Xcode project, because it's too easy to confuse with Apple-lldb-macOS.cmake ``` When building with Xcode, we recommend using the corresponding cache script. If this was a mistake, clean your build directory and re-run CMake with: -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject ``` Also set the generator inside the cache script. Reviewers: JDevlieghere, jingham, clayborg Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368066
2019-08-07 01:21:34 +08:00
" -C ${CMAKE_SOURCE_DIR}/cmake/caches/Apple-lldb-Xcode.cmake\n"
"See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject\n")
endif()
endif()
cmake: provide flag that enables 'log enable --stack' to provide useful file/function info on POSIX systems Adding the following flag to a cmake line: -DLLDB_EXPORT_ALL_SYMBOLS=TRUE will cause all symbols to be exported from liblldb. This enables the llvm backtrace mechanism to see and report backtrace symbols properly when using (lldb) log enable --stack ... Prior to this change, only the SB API symbols would show up on Linux and other systems that use a public-symbols-based backtrace lookup mechanism. log enable --stack ... is a very handy, quick way to understand the flow of how some log lines are getting hit within lldb without having to hook up a top-level debugger over your current debug session. llvm-svn: 250299
2015-10-14 22:52:15 +08:00
if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
set(LLDB_EXPORT_ALL_SYMBOLS 0 CACHE BOOL
"Causes lldb to export all symbols when building liblldb.")
else()
# Windows doesn't support toggling this, so don't bother making it a
# cache variable.
set(LLDB_EXPORT_ALL_SYMBOLS 0)
endif()
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
if ((NOT MSVC) OR MSVC12)
add_definitions( -DHAVE_ROUND )
endif()
Re-land "[lldb/CMake] Change how we deal with optional dependencies" Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
2019-12-21 07:38:46 +08:00
# Check if we libedit capable of handling wide characters (built with
# '--enable-widec').
[lldb/CMake] Rename LLDB_DISABLE_LIBEDIT to LLDB_ENABLE_LIBEDIT This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71380
2019-12-13 01:22:34 +08:00
if (LLDB_ENABLE_LIBEDIT)
[lldb/CMake] Fix variable naming in FindLibEdit The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by find_package_handle_standard_args. However this isn't valid for the package name. The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and "LIBEDIT_FOUND" are valid names. This fixes all the variables set by FindLibEdit to match the desired naming scheme.
2020-01-03 05:31:32 +08:00
set(CMAKE_REQUIRED_LIBRARIES ${LibEdit_LIBRARIES})
set(CMAKE_REQUIRED_INCLUDES ${LibEdit_INCLUDE_DIRS})
[cmake] Move LLDB_DISABLE_LIBEDIT handling code into a central place This was previously scattered between the main CMakeLists.txt file and LLDBGenerateConfig.cmake and LLDBConfig.cmake. This caused the some of the code to be executed in incorrect order. Specifically, the check for el_winsertstr was done before libedit_LIBRARIES was computed, and so it always failed on the first run. Moving it the two checks to a central place makes sure this doesn't happen again and improves the overall readability. llvm-svn: 355103
2019-03-01 00:04:54 +08:00
check_symbol_exists(el_winsertstr histedit.h LLDB_EDITLINE_USE_WCHAR)
set(CMAKE_EXTRA_INCLUDE_FILES histedit.h)
check_type_size(el_rfunc_t LLDB_EL_RFUNC_T_SIZE)
if (LLDB_EL_RFUNC_T_SIZE STREQUAL "")
set(LLDB_HAVE_EL_RFUNC_T 0)
else()
set(LLDB_HAVE_EL_RFUNC_T 1)
endif()
set(CMAKE_REQUIRED_LIBRARIES)
set(CMAKE_REQUIRED_INCLUDES)
set(CMAKE_EXTRA_INCLUDE_FILES)
endif()
[lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
2019-12-14 02:37:33 +08:00
if (LLDB_ENABLE_PYTHON)
Allow customized relative PYTHONHOME (Attemp 1) Summary: This is another attempt of 0bb90628b5f7c170689d2d3f019af773772fc649. The difference is that g_python_home is not declared as const. Since some versions of python do not expect that. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74998
2020-02-22 07:52:15 +08:00
if(CMAKE_SYSTEM_NAME MATCHES "Windows")
set(default_embed_python_home ON)
else()
set(default_embed_python_home OFF)
endif()
option(LLDB_EMBED_PYTHON_HOME
"Embed PYTHONHOME in the binary. If set to OFF, PYTHONHOME environment variable will be used to to locate Python."
${default_embed_python_home})
[lldb] Get rid of helper CMake variables for Python This patch is a big sed to rename the following variables: s/PYTHON_LIBRARIES/Python3_LIBRARIES/g s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g s/PYTHON_RPATH/Python3_RPATH/g I've also renamed the CMake module to better express its purpose and for consistency with FindLuaAndSwig. Differential revision: https://reviews.llvm.org/D85976
2020-08-17 23:47:52 +08:00
include_directories(${Python3_INCLUDE_DIRS})
Allow customized relative PYTHONHOME (Attemp 1) Summary: This is another attempt of 0bb90628b5f7c170689d2d3f019af773772fc649. The difference is that g_python_home is not declared as const. Since some versions of python do not expect that. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74998
2020-02-22 07:52:15 +08:00
if (LLDB_EMBED_PYTHON_HOME)
[lldb] Get rid of helper CMake variables for Python This patch is a big sed to rename the following variables: s/PYTHON_LIBRARIES/Python3_LIBRARIES/g s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g s/PYTHON_RPATH/Python3_RPATH/g I've also renamed the CMake module to better express its purpose and for consistency with FindLuaAndSwig. Differential revision: https://reviews.llvm.org/D85976
2020-08-17 23:47:52 +08:00
get_filename_component(PYTHON_HOME "${Python3_EXECUTABLE}" DIRECTORY)
Allow customized relative PYTHONHOME (Attemp 1) Summary: This is another attempt of 0bb90628b5f7c170689d2d3f019af773772fc649. The difference is that g_python_home is not declared as const. Since some versions of python do not expect that. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74998
2020-02-22 07:52:15 +08:00
set(LLDB_PYTHON_HOME "${PYTHON_HOME}" CACHE STRING
"Path to use as PYTHONHOME in lldb. If a relative path is specified, it will be resolved at runtime relative to liblldb directory.")
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
endif()
endif()
Correctly include LLVM_EXTERNAL_CLANG_SOURCE_DIR. Reviewers: sas, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14166 llvm-svn: 251589
2015-10-29 08:48:38 +08:00
if (LLVM_EXTERNAL_CLANG_SOURCE_DIR)
include_directories(${LLVM_EXTERNAL_CLANG_SOURCE_DIR}/include)
else ()
include_directories(${CMAKE_SOURCE_DIR}/tools/clang/include)
endif ()
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
include_directories("${CMAKE_CURRENT_BINARY_DIR}/../clang/include")
# Disable GCC warnings
[lldb] Simplify CMake logic with LLVM's append_if function Use the append_if CMake function from HandleLLVMOptions. Since we include this file in LLDBStandalone it should work in both for in-tree and out-of-tree builds.
2020-08-21 13:32:31 +08:00
check_cxx_compiler_flag("-Wno-deprecated-declarations" CXX_SUPPORTS_NO_DEPRECATED_DECLARATIONS)
append_if(CXX_SUPPORTS_NO_DEPRECATED_DECLARATIONS "-Wno-deprecated-declarations" CMAKE_CXX_FLAGS)
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
[lldb] Simplify CMake logic with LLVM's append_if function Use the append_if CMake function from HandleLLVMOptions. Since we include this file in LLDBStandalone it should work in both for in-tree and out-of-tree builds.
2020-08-21 13:32:31 +08:00
check_cxx_compiler_flag("-Wno-unknown-pragmas" CXX_SUPPORTS_NO_UNKNOWN_PRAGMAS)
append_if(CXX_SUPPORTS_NO_UNKNOWN_PRAGMAS "-Wno-unknown-pragmas" CMAKE_CXX_FLAGS)
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
[lldb] Simplify CMake logic with LLVM's append_if function Use the append_if CMake function from HandleLLVMOptions. Since we include this file in LLDBStandalone it should work in both for in-tree and out-of-tree builds.
2020-08-21 13:32:31 +08:00
check_cxx_compiler_flag("-Wno-strict-aliasing" CXX_SUPPORTS_NO_STRICT_ALIASING)
append_if(CXX_SUPPORTS_NO_STRICT_ALIASING "-Wno-strict-aliasing" CMAKE_CXX_FLAGS)
Disable the strict-aliasing warnings produced by gcc GCC produce a lot of strict-aliasing warning for the LLDB codebase what makes reading the compile output very difficult. This change disable these warnings to reduce the noise as we already ignore them. We should consider re-enabling the warning if we fix all (or most) strict-aliasing violation first. Differential revision: http://reviews.llvm.org/D13981 llvm-svn: 251107
2015-10-23 18:34:53 +08:00
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
# Disable Clang warnings
[lldb] Simplify CMake logic with LLVM's append_if function Use the append_if CMake function from HandleLLVMOptions. Since we include this file in LLDBStandalone it should work in both for in-tree and out-of-tree builds.
2020-08-21 13:32:31 +08:00
check_cxx_compiler_flag("-Wno-deprecated-register" CXX_SUPPORTS_NO_DEPRECATED_REGISTER)
append_if(CXX_SUPPORTS_NO_DEPRECATED_REGISTER "-Wno-deprecated-register" CMAKE_CXX_FLAGS)
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
[lldb] Simplify CMake logic with LLVM's append_if function Use the append_if CMake function from HandleLLVMOptions. Since we include this file in LLDBStandalone it should work in both for in-tree and out-of-tree builds.
2020-08-21 13:32:31 +08:00
check_cxx_compiler_flag("-Wno-vla-extension" CXX_SUPPORTS_NO_VLA_EXTENSION)
append_if(CXX_SUPPORTS_NO_VLA_EXTENSION "-Wno-vla-extension" CMAKE_CXX_FLAGS)
Use -Wno-vla-extension globally. Summary: This was previously only established within debugserver, but there is a use of the VLA extension in source/Host/macosx/Symbols.cpp, so ignore this warning globally. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12515 llvm-svn: 246605
2015-09-02 07:43:51 +08:00
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
# Disable MSVC warnings
if( MSVC )
add_definitions(
-wd4018 # Suppress 'warning C4018: '>=' : signed/unsigned mismatch'
-wd4068 # Suppress 'warning C4068: unknown pragma'
-wd4150 # Suppress 'warning C4150: deletion of pointer to incomplete type'
[cmake] Suppress 'warning C4201: nonstandard extension used: nameless struct/union' on Windows This warning comes up in the ObjC language plugin because of the use of nameless structs. This change suppresses the warning. llvm-svn: 349977
2018-12-22 07:59:24 +08:00
-wd4201 # Suppress 'warning C4201: nonstandard extension used: nameless struct/union'
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
-wd4251 # Suppress 'warning C4251: T must have dll-interface to be used by clients of class U.'
-wd4521 # Suppress 'warning C4521: 'type' : multiple copy constructors specified'
-wd4530 # Suppress 'warning C4530: C++ exception handler used, but unwind semantics are not enabled.'
)
Fix liblldb linking on RHEL 6 (bug #24140) Patch by Eugene Zelenko. llvm-svn: 242525
2015-07-17 23:26:27 +08:00
endif()
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
Unicode support on Win32. Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
2016-03-23 01:58:09 +08:00
# Use the Unicode (UTF-16) APIs by default on Win32
if (CMAKE_SYSTEM_NAME MATCHES "Windows")
Fix build for mingw. Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there. Reviewers: zturner, labath, abidh Subscribers: ki.stfu, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D27759 llvm-svn: 289821
2016-12-15 23:00:41 +08:00
add_definitions( -D_UNICODE -DUNICODE )
Unicode support on Win32. Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
2016-03-23 01:58:09 +08:00
endif()
[CMake] Allow version overrides with -DLLDB_VERSION_MAJOR/MINOR/PATCH/SUFFIX Summary: This follows the approach in Clang. If no overrides are given, LLDB_VERSION_* is inferred from LLVM_VERSION_*. This mimics the current behaviour (PACKAGE_VERSION itself is generated from LLVM_VERSION_*). For in-tree builds LLVM_VERSION_* will be defined at this point already. For standalone builds, LLDBConfig.cmake is included after LLDBStandalone.cmake which includes LLVMConfig.cmake. Reviewers: labath, xiaobai Subscribers: mgorny, friss, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D54333 llvm-svn: 346668
2018-11-13 00:22:28 +08:00
# If LLDB_VERSION_* is specified, use it, if not use LLVM_VERSION_*.
if(NOT DEFINED LLDB_VERSION_MAJOR)
set(LLDB_VERSION_MAJOR ${LLVM_VERSION_MAJOR})
endif()
if(NOT DEFINED LLDB_VERSION_MINOR)
set(LLDB_VERSION_MINOR ${LLVM_VERSION_MINOR})
endif()
if(NOT DEFINED LLDB_VERSION_PATCH)
set(LLDB_VERSION_PATCH ${LLVM_VERSION_PATCH})
endif()
if(NOT DEFINED LLDB_VERSION_SUFFIX)
set(LLDB_VERSION_SUFFIX ${LLVM_VERSION_SUFFIX})
endif()
set(LLDB_VERSION "${LLDB_VERSION_MAJOR}.${LLDB_VERSION_MINOR}.${LLDB_VERSION_PATCH}${LLDB_VERSION_SUFFIX}")
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
message(STATUS "LLDB version: ${LLDB_VERSION}")
[lldb][ELF] Read symbols from .gnu_debugdata sect. Summary: If the .symtab section is stripped from the binary it might be that there's a .gnu_debugdata section which contains a smaller .symtab in order to provide enough information to create a backtrace with function names or to set and hit a breakpoint on a function name. This change looks for a .gnu_debugdata section in the ELF object file. The .gnu_debugdata section contains a xz-compressed ELF file with a .symtab section inside. Symbols from that compressed .symtab section are merged with the main object file's .dynsym symbols (if any). In addition we always load the .dynsym even if there's a .symtab section. For example, the Fedora and RHEL operating systems strip their binaries but keep a .gnu_debugdata section. While gdb already can read this section, LLDB until this patch couldn't. To test this patch on a Fedora or RHEL operating system, try to set a breakpoint on the "help" symbol in the "zip" binary. Before this patch, only GDB can set this breakpoint; now LLDB also can do so without installing extra debug symbols: lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h The above line runs LLDB in batch mode and on the "/usr/bin/zip -h" target: (lldb) target create "/usr/bin/zip" Current executable set to '/usr/bin/zip' (x86_64). (lldb) settings set -- target.run-args "-h" Before the program starts, we set a breakpoint on the "help" symbol: (lldb) b help Breakpoint 1: where = zip`help, address = 0x00000000004093b0 Once the program is run and has hit the breakpoint we ask for a backtrace: (lldb) r Process 10073 stopped * thread #1, name = 'zip', stop reason = breakpoint 1.1 frame #0: 0x00000000004093b0 zip`help zip`help: -> 0x4093b0 <+0>: pushq %r12 0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056 0x4093b9 <+9>: movl $0x1, %edi 0x4093be <+14>: xorl %eax, %eax Process 10073 launched: '/usr/bin/zip' (x86_64) (lldb) bt * thread #1, name = 'zip', stop reason = breakpoint 1.1 * frame #0: 0x00000000004093b0 zip`help frame #1: 0x0000000000403970 zip`main + 3248 frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243 frame #3: 0x0000000000408cee zip`_start + 46 In order to support the .gnu_debugdata section, one has to have LZMA development headers installed. The CMake section, that controls this part looks for the LZMA headers and enables .gnu_debugdata support by default if they are found; otherwise or if explicitly requested, the minidebuginfo support is disabled. GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6 (2013). Reviewers: espindola, labath, jankratochvil, alexshap Reviewed By: labath Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D66791 llvm-svn: 373891
2019-10-07 18:32:16 +08:00
if (LLDB_ENABLE_LZMA)
include_directories(${LIBLZMA_INCLUDE_DIRS})
endif()
[lldb/CMake] Use LLDB's autodetection logic for libxml2 Libxml2 is already an optional dependency. It should use the same infrastructure as the other dependencies. Differential revision: https://reviews.llvm.org/D72290
2020-01-09 01:03:40 +08:00
if (LLDB_ENABLE_LIBXML2)
include_directories(${LIBXML2_INCLUDE_DIR})
endif()
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
include_directories(BEFORE
[CMake] Support generating Config.h Summary: This patch removes the hand maintained config files in favor of auto-generating the config file. We will still need to maintain the defines for the Xcode builds on Mac, but all CMake builds use the generated header instead. This will enable finer grained platform support tests and enable supporting LLDB on more platforms with less manual maintenance. I have only tested this patch on Darwin, and any help testing it out on other platforms would be greatly appreciated. I've probably messed something up somewhere. Reviewers: labath, zturner Reviewed By: labath Subscribers: krytarowski, emaste, srhines, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D31969 llvm-svn: 300372
2017-04-15 06:03:45 +08:00
${CMAKE_CURRENT_BINARY_DIR}/include
Remove xcode-specific Config.h Summary: Now that the xcode project is removed, we no longer need/use the hand-maintained Config.h file, as everything is configured through cmake. This patch deletes that file and reverts some of the changes from r300372, which were made to support this use case. Reviewers: sgraenitz, beanz Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D65862 llvm-svn: 368266
2019-08-08 16:27:25 +08:00
${CMAKE_CURRENT_SOURCE_DIR}/include
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
)
Add Support for LLVM_INSTALL_TOOLCHAIN_ONLY (bug #23784) Support for LLVM_INSTALL_TOOLCHAIN_ONLY is modeled on same functionality from LLVM and Clang CMake files. Patch by: Eugene Zelenko llvm-svn: 240935
2015-06-29 19:03:21 +08:00
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
install(DIRECTORY include/
Install lldb's SB headers (pr36630) These were removed in r309021 in what looks like an accidentally committed change. This brings them back. I also rename the header component to lldb-headers (instead of lldb_headers) to match the llvm style and add a special install-lldb-headers target, which installs just the headers. llvm-svn: 327016
2018-03-08 23:52:46 +08:00
COMPONENT lldb-headers
Add Support for LLVM_INSTALL_TOOLCHAIN_ONLY (bug #23784) Support for LLVM_INSTALL_TOOLCHAIN_ONLY is modeled on same functionality from LLVM and Clang CMake files. Patch by: Eugene Zelenko llvm-svn: 240935
2015-06-29 19:03:21 +08:00
DESTINATION include
FILES_MATCHING
PATTERN "*.h"
[CMake] Support generating Config.h Summary: This patch removes the hand maintained config files in favor of auto-generating the config file. We will still need to maintain the defines for the Xcode builds on Mac, but all CMake builds use the generated header instead. This will enable finer grained platform support tests and enable supporting LLDB on more platforms with less manual maintenance. I have only tested this patch on Darwin, and any help testing it out on other platforms would be greatly appreciated. I've probably messed something up somewhere. Reviewers: labath, zturner Reviewed By: labath Subscribers: krytarowski, emaste, srhines, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D31969 llvm-svn: 300372
2017-04-15 06:03:45 +08:00
PATTERN ".cmake" EXCLUDE
)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/
Install lldb's SB headers (pr36630) These were removed in r309021 in what looks like an accidentally committed change. This brings them back. I also rename the header component to lldb-headers (instead of lldb_headers) to match the llvm style and add a special install-lldb-headers target, which installs just the headers. llvm-svn: 327016
2018-03-08 23:52:46 +08:00
COMPONENT lldb-headers
[CMake] Support generating Config.h Summary: This patch removes the hand maintained config files in favor of auto-generating the config file. We will still need to maintain the defines for the Xcode builds on Mac, but all CMake builds use the generated header instead. This will enable finer grained platform support tests and enable supporting LLDB on more platforms with less manual maintenance. I have only tested this patch on Darwin, and any help testing it out on other platforms would be greatly appreciated. I've probably messed something up somewhere. Reviewers: labath, zturner Reviewed By: labath Subscribers: krytarowski, emaste, srhines, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D31969 llvm-svn: 300372
2017-04-15 06:03:45 +08:00
DESTINATION include
FILES_MATCHING
PATTERN "*.h"
PATTERN ".cmake" EXCLUDE
Add Support for LLVM_INSTALL_TOOLCHAIN_ONLY (bug #23784) Support for LLVM_INSTALL_TOOLCHAIN_ONLY is modeled on same functionality from LLVM and Clang CMake files. Patch by: Eugene Zelenko llvm-svn: 240935
2015-06-29 19:03:21 +08:00
)
Install lldb's SB headers (pr36630) These were removed in r309021 in what looks like an accidentally committed change. This brings them back. I also rename the header component to lldb-headers (instead of lldb_headers) to match the llvm style and add a special install-lldb-headers target, which installs just the headers. llvm-svn: 327016
2018-03-08 23:52:46 +08:00
add_custom_target(lldb-headers)
[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-headers PROPERTIES FOLDER "lldb misc")
Install lldb's SB headers (pr36630) These were removed in r309021 in what looks like an accidentally committed change. This brings them back. I also rename the header component to lldb-headers (instead of lldb_headers) to match the llvm style and add a special install-lldb-headers target, which installs just the headers. llvm-svn: 327016
2018-03-08 23:52:46 +08:00
if (NOT CMAKE_CONFIGURATION_TYPES)
add_llvm_install_targets(install-lldb-headers
COMPONENT lldb-headers)
endif()
Add Support for LLVM_INSTALL_TOOLCHAIN_ONLY (bug #23784) Support for LLVM_INSTALL_TOOLCHAIN_ONLY is modeled on same functionality from LLVM and Clang CMake files. Patch by: Eugene Zelenko llvm-svn: 240935
2015-06-29 19:03:21 +08:00
endif()
Adds lldb support for querying the register mapping from gdbserver remote targets using qXfer:features:read packet. Only enabled if libxml2 enabled in build. Differential Revision: http://reviews.llvm.org/D8999 llvm-svn: 235109
2015-04-16 23:51:33 +08:00
[lldb] Symlink the Clang resource directory to the LLDB build directory in standalone builds When doing a standalone build (i.e., building just LLDB against an existing LLVM/Clang installation), LLDB is currently unable to find any Clang resource directory that contains all the builtin headers we need to parse real source code. This causes several tests that actually parse source code on disk within the expression parser to fail (most notably nearly all the import-std-module tests). The reason why LLDB can't find the resource directory is that we search based on the path of the LLDB shared library path. We assumed that the Clang resource directory is in the same prefix and has the same relative path to the LLDB shared library (e.g., `../clang/10.0.0/include`). However for a standalone build where the existing Clang can be anywhere on the disk, so we can't just rely on the hardcoded relative paths to the LLDB shared library. It seems we can either solve this by copying the resource directory to the LLDB installation, symlinking it there or we pass the path to the Clang installation to the code that is trying to find the resource directory. When building the LLDB framework we currently copy the resource directory over to the framework folder (this is why the import-std-module are not failing on the Green Dragon standalone bot). This patch symlinks the resource directory of Clang into the LLDB build directory. The reason for that is simply that this is only needed when running LLDB from the build directory. Once LLDB and Clang/LLVM are installed the already existing logic can find the Clang resource directory by searching relative to the LLDB shared library. Reviewed By: kastiglione, JDevlieghere Differential Revision: https://reviews.llvm.org/D88581
2020-10-06 15:27:24 +08:00
# If LLDB is building against a prebuilt Clang, then the Clang resource
# directory that LLDB is using for its embedded Clang instance needs to point
# to the resource directory of the used Clang installation.
if (NOT TARGET clang-resource-headers)
set(LLDB_CLANG_RESOURCE_DIR_NAME "${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
# Iterate over the possible places where the external resource directory
# could be and pick the first that exists.
foreach(CANDIDATE "${Clang_DIR}/../.." "${LLVM_DIR}" "${LLVM_LIBRARY_DIRS}"
"${LLVM_BUILD_LIBRARY_DIR}"
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}")
# Build the resource directory path by appending 'clang/<version number>'.
set(CANDIDATE_RESOURCE_DIR "${CANDIDATE}/clang/${LLDB_CLANG_RESOURCE_DIR_NAME}")
if (IS_DIRECTORY "${CANDIDATE_RESOURCE_DIR}")
set(LLDB_EXTERNAL_CLANG_RESOURCE_DIR "${CANDIDATE_RESOURCE_DIR}")
break()
endif()
endforeach()
if (NOT LLDB_EXTERNAL_CLANG_RESOURCE_DIR)
message(FATAL_ERROR "Expected directory for clang-resource headers not found: ${LLDB_EXTERNAL_CLANG_RESOURCE_DIR}")
endif()
endif()
[lldb/CMake] Use LLDB's autodetection logic for libxml2 Libxml2 is already an optional dependency. It should use the same infrastructure as the other dependencies. Differential revision: https://reviews.llvm.org/D72290
2020-01-09 01:03:40 +08:00
# Find Apple-specific libraries or frameworks that may be needed.
[CMake] A few fixups to support building LLDB for iOS These changes enable proper configuration of LLDB targeting iOS. llvm-svn: 308378
2017-07-19 05:15:53 +08:00
if (APPLE)
Build a flat LLDB.framework for embedded Darwin targets This patch configures LLDB.framework to build as a flat unversioned framework on non-macOS Darwin targets, which have never supported the macOS framework layout. This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to reflect the fact that lldb is built for several different kinds of embedded Darwin targets, not just iOS. Differential Revision: https://reviews.llvm.org/D85770
2020-08-12 03:18:19 +08:00
if(NOT APPLE_EMBEDDED)
[CMake] A few fixups to support building LLDB for iOS These changes enable proper configuration of LLDB targeting iOS. llvm-svn: 308378
2017-07-19 05:15:53 +08:00
find_library(CARBON_LIBRARY Carbon)
find_library(CORE_SERVICES_LIBRARY CoreServices)
endif()
Fix line endings. I must have committed these with windows line endings a few months ago when I did this work. llvm-svn: 237283
2015-05-14 03:45:06 +08:00
find_library(FOUNDATION_LIBRARY Foundation)
find_library(CORE_FOUNDATION_LIBRARY CoreFoundation)
Adds lldb support for querying the register mapping from gdbserver remote targets using qXfer:features:read packet. Only enabled if libxml2 enabled in build. Differential Revision: http://reviews.llvm.org/D8999 llvm-svn: 235109
2015-04-16 23:51:33 +08:00
find_library(SECURITY_LIBRARY Security)
[lldb] Cleans up system_libs Summary: Long long ago system_libs was appended to LLDB_SYSTEM_LIBS in cmake/LLDBDependencies.cmake. After that file was removed, system_libs is orphaned. Currently the only user is source/Utility. Move the logic there and remove system_libs. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D80253
2020-05-20 06:23:35 +08:00
include_directories(${LIBXML2_INCLUDE_DIR})
Adds lldb support for querying the register mapping from gdbserver remote targets using qXfer:features:read packet. Only enabled if libxml2 enabled in build. Differential Revision: http://reviews.llvm.org/D8999 llvm-svn: 235109
2015-04-16 23:51:33 +08:00
endif()
[cmake] Fix standalone+LLVM_LINK_LLVM_DYLIB builds (pr36687) Summary: To make this build work, I needed to add detection code for the pthread library. This is necessary, because we have direct calls to these libraries (instead of going through llvm) and in the standalone build we cannot rely on llvm to detect these for us. In a standalone non-dylib build this was accidentaly working because these libraries were pulled in as an interface dependency of the .a files, but in a dylib build these are no longer part of the link interface, and so we need to add them explicitly. Reviewers: krytarowski, zturner Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D44379 llvm-svn: 327490
2018-03-14 18:08:21 +08:00
if( WIN32 AND NOT CYGWIN )
set(PURE_WINDOWS 1)
endif()
[lldb] Enable building with Cmake/BUILD_SHARED_LIBS Summary: Several changes to fix CMake builds of LLDB with the BUILD_SHARED_LIBS setting on. - Force all internal libraries to be built STATIC. - Add additional library dependencies (pthread, dl, runtimedyld). - modify finalisation of SWIG wrapper to symlink the "lib" dir into python/site-packages, so _lldb.so's RPATH resolves. Test Plan: Verified one test case with "dotest.py". Reviewers: sylvestre.ledru, zturner Reviewed By: zturner Subscribers: zturner, ted, tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D10157 llvm-svn: 239007
2015-06-04 11:12:37 +08:00
[cmake] Fix standalone+LLVM_LINK_LLVM_DYLIB builds (pr36687) Summary: To make this build work, I needed to add detection code for the pthread library. This is necessary, because we have direct calls to these libraries (instead of going through llvm) and in the standalone build we cannot rely on llvm to detect these for us. In a standalone non-dylib build this was accidentaly working because these libraries were pulled in as an interface dependency of the .a files, but in a dylib build these are no longer part of the link interface, and so we need to add them explicitly. Reviewers: krytarowski, zturner Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D44379 llvm-svn: 327490
2018-03-14 18:08:21 +08:00
if(NOT PURE_WINDOWS)
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
find_package(Threads REQUIRED)
[lldb] Enable building with Cmake/BUILD_SHARED_LIBS Summary: Several changes to fix CMake builds of LLDB with the BUILD_SHARED_LIBS setting on. - Force all internal libraries to be built STATIC. - Add additional library dependencies (pthread, dl, runtimedyld). - modify finalisation of SWIG wrapper to symlink the "lib" dir into python/site-packages, so _lldb.so's RPATH resolves. Test Plan: Verified one test case with "dotest.py". Reviewers: sylvestre.ledru, zturner Reviewed By: zturner Subscribers: zturner, ted, tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D10157 llvm-svn: 239007
2015-06-04 11:12:37 +08:00
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
# Figure out if lldb could use lldb-server. If so, then we'll
# ensure we build lldb-server when an lldb target is being built.
Enable lldb-server on Windows Summary: This commit contains three small changes to enable lldb-server on Windows. - Add lldb-server for Windows to the build - Disable pty redirection on Windows for the initial lldb-server bring up - Add a support to get the parent pid for a process on Windows - Ifdef some signals which aren't supported on Windows Thanks to Hui Huang for the help with this patch! Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61686 llvm-svn: 368774
2019-08-14 07:50:54 +08:00
if (CMAKE_SYSTEM_NAME MATCHES "Android|Darwin|FreeBSD|Linux|NetBSD|Windows")
[CMake] Align debugserver with lldb-server on Darwin Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here. Reviewers: xiaobai, JDevlieghere, davide Reviewed By: xiaobai, JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64994 llvm-svn: 366631
2019-07-20 19:18:31 +08:00
set(LLDB_CAN_USE_LLDB_SERVER ON)
[CMake] Reinstate LLDB_CAN_USE_LLDB_SERVER We cannot manipulate the LLDB_TOOL_LLDB_SERVER_BUILD directly from LLDBConfig.cmake because this would set the variable before the option is defined in AddLLVM.cmake. Instead, we need to use the LLDB_CAN_USE_LLDB_SERVER variable to conditionally add the lldb-server subdirectory. This should ensure the variable doesn't get cleared. llvm-svn: 360631
2019-05-14 06:55:11 +08:00
else()
[CMake] Align debugserver with lldb-server on Darwin Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here. Reviewers: xiaobai, JDevlieghere, davide Reviewed By: xiaobai, JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64994 llvm-svn: 366631
2019-07-20 19:18:31 +08:00
set(LLDB_CAN_USE_LLDB_SERVER OFF)
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
endif()
# Figure out if lldb could use debugserver. If so, then we'll
# ensure we build debugserver when we build lldb.
[CMake] Align debugserver with lldb-server on Darwin Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here. Reviewers: xiaobai, JDevlieghere, davide Reviewed By: xiaobai, JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64994 llvm-svn: 366631
2019-07-20 19:18:31 +08:00
if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
set(LLDB_CAN_USE_DEBUGSERVER ON)
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
else()
[CMake] Align debugserver with lldb-server on Darwin Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here. Reviewers: xiaobai, JDevlieghere, davide Reviewed By: xiaobai, JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64994 llvm-svn: 366631
2019-07-20 19:18:31 +08:00
set(LLDB_CAN_USE_DEBUGSERVER OFF)
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
endif()
Use library discovery for curses and panel Summary: This approach is tunable with custom paths for curses library. It also detects whether there are requirements met. I make use of it on NetBSD. Patch by Kamil Rytarowski. Thanks! Reviewers: clayborg Subscribers: brucem, joerg, lldb-commits Differential Revision: http://reviews.llvm.org/D14529 llvm-svn: 253151
2015-11-15 09:53:23 +08:00
Fix android-i386 build broken by previous commit I foolishly thought I could simplify the condition to cover all android targets. I was wrong - i386 headers don't define __NR_accept. Revert back to enabling the workaround on arm an mips only. llvm-svn: 293282
2017-01-27 20:58:23 +08:00
if ((CMAKE_SYSTEM_NAME MATCHES "Android") AND LLVM_BUILD_STATIC AND
((ANDROID_ABI MATCHES "armeabi") OR (ANDROID_ABI MATCHES "mips")))
Address post-commit review remarks Tamas pointed out that the macro name I used in r293282 was too vague. Rename it to better reflect what it is used for. llvm-svn: 293287
2017-01-27 23:19:03 +08:00
add_definitions(-DANDROID_USE_ACCEPT_WORKAROUND)
Refactor the android accept hack This moves the accept hack from the android toolchain file into LLDBConfig.cmake. This allows successful lldb android compilation without relying on our custom toolchain file. llvm-svn: 293281
2017-01-27 20:23:51 +08:00
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(LLDBGenerateConfig)