Magic-Mirror/llvm-capstone
1
0
Fork 0
mirror of https://github.com/capstone-engine/llvm-capstone.git synced 2025-02-17 08:21:13 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity
llvm-capstone/lldb/CMakeLists.txt

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

152 lines
4.9 KiB
CMake
Raw Normal View History

Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 18:12:32 +02:00
cmake_minimum_required(VERSION 3.20.0)
Standalone cmake build improvements (bug #23889) patch by Eugene Zelenko. llvm-svn: 242529
2015-07-17 15:50:48 +00:00
Harmonize cmake_policy() across standalone builds of all projects Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared `cmake/modules/CMakePolicy.cmake`. Include it from all relevant projects that support standalone builds, in order to ensure that the policies are consistently set whether they are built in-tree or stand-alone. Differential Revision: https://reviews.llvm.org/D136572
2022-10-24 06:31:37 +02:00
if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
endif()
include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
NO_POLICY_SCOPE)
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 13:23:15 +00: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-27 16:04:26 +00: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-17 16:47:02 +00: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-29 23:09:31 +00:00
project(lldb)
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
set(LLDB_BUILT_STANDALONE TRUE)
[lldb] Restore default setting of LLDB_INCLUDE_TESTS in standalone builds In 52f39853abd46495a6d636c4b035e1b92cf4b833 the option LLDB_INCLUDE_TESTS was moved above the inclusion of LLDBStandalone. This isn't a problem per-se, but it changes the default value of LLDB_INCLUDE_TESTS in standalone builds. LLDBStandalone explicitly sets LLVM_INCLUDE_TESTS to true, indicating that for standalone builds this is considered the default behavior. This patch restores said default behavior. Differential Revision: https://reviews.llvm.org/D138237
2022-11-17 13:46:40 -08:00
set(LLVM_INCLUDE_TESTS ON CACHE INTERNAL "")
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
endif()
# Must go below project(..)
include(GNUInstallDirs)
[lldb] Include gtest in standalone build only if LLDB_INCLUDE_TESTS Build gtest targets when building standalone only if LLDB_INCLUDE_TESTS is true. Prior to this change, they were built whenever LLVM_MAIN_SRC_DIR was available, independently whether tests themselves would be run. Differential Revision: https://reviews.llvm.org/D136551
2022-10-23 14:47:50 +02:00
option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests." ${LLVM_INCLUDE_TESTS})
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
if(LLDB_BUILT_STANDALONE)
[LLVM] Update C++ standard to 17 Also make the soft toolchain requirements hard. This allows us to use C++17 features in LLVM now. If we find patterns with C++17 that improve readability it should be recommended in the coding standards. Reviewed By: jhenderson, cor3ntin, MaskRay Differential Revision: https://reviews.llvm.org/D130689
2022-08-05 21:45:55 +02:00
set(CMAKE_CXX_STANDARD 17 CACHE STRING "C++ standard to conform to")
build: make standalone builds work again Apple's greendragon bot uses a standalone build of lldb which would fail to build after a recent change to LLVM as it relied on LLVM setting global flags for its build. Attempt to repair the standalone build for greendragon bot.
2019-10-29 08:24:10 -07:00
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_CXX_EXTENSIONS NO)
[lldb] Set CMAKE_CXX_STANDARD before including LLDBStandalone Set the C++ language standard before including LLDBStandalone.cmake. Otherwise we risk building some of our dependencies (such as llvm_gtest) without C++ 17 support. This should fix the standalone bot [1] which is currently failing with the following error: test-port.h:841:12: error: no member named 'tuple' in namespace 'std' using std::tuple; [1] https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone
2023-05-15 14:29:20 -07:00
include(LLDBStandalone)
[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-17 16:47:02 +00: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-27 16:04:26 +00: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-28 17:06:04 +00: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 13:23:15 +00:00
# Define the LLDB_CONFIGURATION_xxx matching the build type.
[lldb] Remove redundant add_definitions() in CMake (NFC) Remove the unused LLDB_CONFIGURATION_RELEASE and move LLDB_USE_OS_LOG under debugserver which is the only one using it.
2020-08-10 22:45:23 -07:00
if(uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
add_definitions(-DLLDB_CONFIGURATION_DEBUG)
[CMake] Enable OS_LOG support on Darwin This gets CMake to match the Xcode project build llvm-svn: 309393
2017-07-28 15:39:50 +00:00
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 00:30:21 +00:00
if (WIN32)
add_definitions(-D_ENABLE_EXTENDED_ALIGNED_STORAGE)
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-13 10:37:33 -08:00
if (LLDB_ENABLE_PYTHON)
[lldb] fix -print-script-interpreter-info on windows Apparently "{sys.prefix}/bin/python3" isn't where you find the python interpreter on windows, so the test I wrote for -print-script-interpreter-info is failing. We can't rely on sys.executable at runtime, because that will point to lldb.exe not python.exe. We can't just record sys.executable from build time, because python could have been moved to a different location. But it should be OK to apply relative path from sys.prefix to sys.executable from build-time to the sys.prefix at runtime. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D113650
2021-11-16 13:50:18 -08:00
set(cachestring_LLDB_PYTHON_RELATIVE_PATH
[lldb] remove usage of distutils, fix python path on debian/ubuntu distutils is deprecated and will be removed, so we shouldn't be using it. We were using it to compute LLDB_PYTHON_RELATIVE_PATH. Discussing a similar issue [at python.org](https://bugs.python.org/issue41282), Filipe Laíns said: If you are relying on the value of distutils.sysconfig.get_python_lib() as you shown in your system, you probably don't want to. That directory (dist-packages) should be for Debian provided packages only, so moving to sysconfig.get_path() would be a good thing, as it has the correct value for user installed packages on your system. So I propose using a relative path from `sys.prefix` to `sysconfig.get_path("platlib")` instead. On Mac and windows, this results in the same paths as we had before, which are `lib/python3.9/site-packages` and `Lib\site-packages`, respectively. On ubuntu however, this will change the path from `lib/python3/dist-packages` to `lib/python3.9/site-packages`. This change seems to be correct, as Filipe said above, `dist-packages` belongs to the distribution, not us. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D114106
2021-11-17 13:14:10 -08:00
"Path where Python modules are installed, relative to LLDB's install prefix")
[lldb] fix -print-script-interpreter-info on windows Apparently "{sys.prefix}/bin/python3" isn't where you find the python interpreter on windows, so the test I wrote for -print-script-interpreter-info is failing. We can't rely on sys.executable at runtime, because that will point to lldb.exe not python.exe. We can't just record sys.executable from build time, because python could have been moved to a different location. But it should be OK to apply relative path from sys.prefix to sys.executable from build-time to the sys.prefix at runtime. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D113650
2021-11-16 13:50:18 -08:00
set(cachestring_LLDB_PYTHON_EXE_RELATIVE_PATH
[lldb] remove usage of distutils, fix python path on debian/ubuntu distutils is deprecated and will be removed, so we shouldn't be using it. We were using it to compute LLDB_PYTHON_RELATIVE_PATH. Discussing a similar issue [at python.org](https://bugs.python.org/issue41282), Filipe Laíns said: If you are relying on the value of distutils.sysconfig.get_python_lib() as you shown in your system, you probably don't want to. That directory (dist-packages) should be for Debian provided packages only, so moving to sysconfig.get_path() would be a good thing, as it has the correct value for user installed packages on your system. So I propose using a relative path from `sys.prefix` to `sysconfig.get_path("platlib")` instead. On Mac and windows, this results in the same paths as we had before, which are `lib/python3.9/site-packages` and `Lib\site-packages`, respectively. On ubuntu however, this will change the path from `lib/python3/dist-packages` to `lib/python3.9/site-packages`. This change seems to be correct, as Filipe said above, `dist-packages` belongs to the distribution, not us. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D114106
2021-11-17 13:14:10 -08:00
"Path to python interpreter exectuable, relative to python's install prefix")
[lldb] use EXT_SUFFIX for python extension LLDB doesn't use only the python stable ABI, which means loading it into an incompatible python can cause the process to crash. _lldb.so should be named with the full EXT_SUFFIX from sysconfig -- such as _lldb.cpython-39-darwin.so -- so this doesn't happen. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D112972
2021-11-16 14:32:03 -08:00
set(cachestring_LLDB_PYTHON_EXT_SUFFIX
"Filename extension for native code python modules")
[LLDB] Don't use the local python to set a default for LLDB_PYTHON_RELATIVE_PATH when cross compiling. Differential Revision: https://reviews.llvm.org/D101903
2021-05-05 13:26:56 +03:00
[lldb] use EXT_SUFFIX for python extension LLDB doesn't use only the python stable ABI, which means loading it into an incompatible python can cause the process to crash. _lldb.so should be named with the full EXT_SUFFIX from sysconfig -- such as _lldb.cpython-39-darwin.so -- so this doesn't happen. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D112972
2021-11-16 14:32:03 -08:00
foreach(var LLDB_PYTHON_RELATIVE_PATH LLDB_PYTHON_EXE_RELATIVE_PATH LLDB_PYTHON_EXT_SUFFIX)
[lldb] fix -print-script-interpreter-info on windows Apparently "{sys.prefix}/bin/python3" isn't where you find the python interpreter on windows, so the test I wrote for -print-script-interpreter-info is failing. We can't rely on sys.executable at runtime, because that will point to lldb.exe not python.exe. We can't just record sys.executable from build time, because python could have been moved to a different location. But it should be OK to apply relative path from sys.prefix to sys.executable from build-time to the sys.prefix at runtime. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D113650
2021-11-16 13:50:18 -08:00
if(NOT DEFINED ${var} AND NOT CMAKE_CROSSCOMPILING)
execute_process(
COMMAND ${Python3_EXECUTABLE}
${CMAKE_CURRENT_SOURCE_DIR}/bindings/python/get-python-config.py
${var}
OUTPUT_VARIABLE value
OUTPUT_STRIP_TRAILING_WHITESPACE)
file(TO_CMAKE_PATH "${value}" value)
set(${var} ${value} CACHE STRING ${cachestring_${var}})
else()
if ("${${var}}" STREQUAL "")
message(FATAL_ERROR
"Crosscompiling LLDB with Python requires manually setting ${var}.")
endif()
endif()
endforeach()
Fix Windows build when python is not explicitly enabled Currently Windows disables Python builds by default. This change ensures we don't process the scripts dir when we're on Windows unless we're explicitly enabling python, which prevents a build error. Change by Deepak Panickal llvm-svn: 212319
2014-07-04 06:43:47 +00:00
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 15:30:55 +00:00
[lldb/lua] Supplement Lua bindings for lldb module Add necessary typemaps for Lua bindings, together with some other files. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela Differential Revision: https://reviews.llvm.org/D108090
2021-10-12 22:08:05 +08:00
if (LLDB_ENABLE_LUA)
find_program(Lua_EXECUTABLE lua5.3)
set(LLDB_LUA_DEFAULT_RELATIVE_PATH "lib/lua/5.3")
set(LLDB_LUA_RELATIVE_PATH ${LLDB_LUA_DEFAULT_RELATIVE_PATH}
CACHE STRING "Path where Lua modules are installed, relative to install prefix")
endif ()
[LLDB] Fix building without SWIG Previously, SWIG was only a hard dependency if python bindings were enabled. Since bf03e17c570171c7a52117fe63ace89d58f328d5, scripts/CMakeLists.txt is included unconditionally, while that file adds the hard dependency on SWIG. Instead, only include that file if either python or lua bindings are enabled.
2019-12-22 10:01:09 +02:00
if (LLDB_ENABLE_PYTHON OR LLDB_ENABLE_LUA)
[lldb/Bindings] Move bindings into their own subdirectory All the code required to generate the language bindings for Python and Lua lives under scripts, even though the majority of this code aren't scripts at all, and surrounded by scripts that are totally unrelated. I've reorganized these files and moved everything related to the language bindings into a new top-level directory named bindings. This makes the corresponding files self contained and much more discoverable. Differential revision: https://reviews.llvm.org/D72437
2020-01-09 07:57:59 -08:00
add_subdirectory(bindings)
[LLDB] Fix building without SWIG Previously, SWIG was only a hard dependency if python bindings were enabled. Since bf03e17c570171c7a52117fe63ace89d58f328d5, scripts/CMakeLists.txt is included unconditionally, while that file adds the hard dependency on SWIG. Instead, only include that file if either python or lua bindings are enabled.
2019-12-22 10:01:09 +02:00
endif ()
[Lldb/Lua] Generate Lua Bindings This patch uses SWIG to generate the Lua bindings for the SB API. It covers most of the API, but some methods require a type map similar to Python. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71235
2019-12-08 15:32:57 -08:00
[lldb] Let LLDB depend on intrinsics_gen to fix non-deterministic module build failures Summary: When building with modules we currently fail randomly to build LLDB's modules and get error messages like below: ``` In file included from <module-includes>:1: In file included from llvm-project/llvm/include/llvm/IR/Argument.h:18: llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found #include "llvm/IR/Attributes.inc" ^~~~~~~~~~~~~~~~~~~~~~~~ ... In file included from llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:9: llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.h:12:10: fatal error: could not build module 'lldb_Wrapper' ``` The reason for this is that our source files can include Clang headers which in turn include files like Attributes.inc which are generated by intrinsics_gen. However, it seems Clang can't express this dependency in its CMake code, so intrinsics_gen is actually not guaranteed to be built before we start parsing LLDB source files and Clang headers. Clang worked around this by letting all libraries depend on intrinsics_gen, which at least lets their builds pass. As I haven't figured out how to solve these dependencies properly and I want to get the LLDB+Modules build green, I suggest we copy Clang's hack until we figure out how to get Clang's dependencies right. Reviewers: sgraenitz, aprantl, JDevlieghere Reviewed By: JDevlieghere Subscribers: mgorny, javed.absar, kristof.beyls, mgrang, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66208 llvm-svn: 368975
2019-08-15 07:29:53 +00:00
# We need the headers generated by instrinsics_gen before we can compile
# any source file in LLDB as the imported Clang modules might include
# some of these generated headers. This approach is copied from Clang's main
# CMakeLists.txt, so it should kept in sync the code in Clang which was added
# in llvm-svn 308844.
[CMake] Make `intrinsics_gen` dependency unconditional. The `intrinsics_gen` target exists in the CMake exports since r309389 (see LLVMConfig.cmake.in), hence projects can depend on `intrinsics_gen` even it they are built separately from LLVM. Reviewed By: MaskRay, JDevlieghere Differential Revision: https://reviews.llvm.org/D83454
2020-07-17 16:43:05 -07:00
if(LLVM_ENABLE_MODULES)
[lldb] Let LLDB depend on intrinsics_gen to fix non-deterministic module build failures Summary: When building with modules we currently fail randomly to build LLDB's modules and get error messages like below: ``` In file included from <module-includes>:1: In file included from llvm-project/llvm/include/llvm/IR/Argument.h:18: llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found #include "llvm/IR/Attributes.inc" ^~~~~~~~~~~~~~~~~~~~~~~~ ... In file included from llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:9: llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.h:12:10: fatal error: could not build module 'lldb_Wrapper' ``` The reason for this is that our source files can include Clang headers which in turn include files like Attributes.inc which are generated by intrinsics_gen. However, it seems Clang can't express this dependency in its CMake code, so intrinsics_gen is actually not guaranteed to be built before we start parsing LLDB source files and Clang headers. Clang worked around this by letting all libraries depend on intrinsics_gen, which at least lets their builds pass. As I haven't figured out how to solve these dependencies properly and I want to get the LLDB+Modules build green, I suggest we copy Clang's hack until we figure out how to get Clang's dependencies right. Reviewers: sgraenitz, aprantl, JDevlieghere Reviewed By: JDevlieghere Subscribers: mgorny, javed.absar, kristof.beyls, mgrang, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66208 llvm-svn: 368975
2019-08-15 07:29:53 +00:00
list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
endif()
[lldb] skip host build for lldb_tblgen with LLDB_TABLEGEN_EXE set When cross compiling lldb-server, do not create a host build for building lldb-tblgeb when LLDB_TABLEGEN_EXE is already provided. This avoids an expensive and time-consuming build step if lldb-tblgen was already built previously for host. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D108053
2021-08-13 13:25:14 -07:00
if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE AND NOT LLDB_TABLEGEN_EXE)
[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 00:21:57 +00:00
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-18 23:40:23 +00: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 00:21:57 +00: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-18 23:40:23 +00: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 00:21:57 +00: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-18 23:40:23 +00: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 00:21:57 +00: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-26 18:14:04 +00: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 15:30:55 +00: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-26 18:14:04 +00:00
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 10:37:32 +00: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-29 16:29:10 +00: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-06 22:21:36 +00:00
[lldb/CMake] Separate CMake code for Lua and Python (NFC) Separate the CMake logic for Lua and Python to clearly distinguish between code specific to either scripting language and the code shared by both. What this patch does is: - Move Python specific code into the bindings/python subdirectory. - Move the Lua specific code into the bindings/lua subdirectory. - Add the _python suffix to Python specific functions/targets. - Fix a dependency issue that would check the binding instead of whether the scripting language is enabled. Note that this patch also changes where the bindings are generated, which might affect downstream projects that check them in. Differential revision: https://reviews.llvm.org/D85708
2020-08-11 08:43:44 -07:00
if (LLDB_ENABLE_PYTHON)
[lldb] Move finish_swig logic into a function in the binding dir Move the finish_swig logic into a function in the bindings directory. By making this a function I can reuse the logic internally where we ship two Python versions and therefore need to finish the bindings twice.
2020-07-29 17:56:38 -07:00
if(LLDB_BUILD_FRAMEWORK)
set(lldb_python_target_dir "${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/Resources/Python/lldb")
else()
set(lldb_python_target_dir "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_PYTHON_RELATIVE_PATH}/lldb")
endif()
[lldb/CMake] Separate CMake code for Lua and Python (NFC) Separate the CMake logic for Lua and Python to clearly distinguish between code specific to either scripting language and the code shared by both. What this patch does is: - Move Python specific code into the bindings/python subdirectory. - Move the Lua specific code into the bindings/lua subdirectory. - Add the _python suffix to Python specific functions/targets. - Fix a dependency issue that would check the binding instead of whether the scripting language is enabled. Note that this patch also changes where the bindings are generated, which might affect downstream projects that check them in. Differential revision: https://reviews.llvm.org/D85708
2020-08-11 08:43:44 -07:00
get_target_property(lldb_python_bindings_dir swig_wrapper_python BINARY_DIR)
Create ${swig_target}-scripts target instead of lldb-python-scripts This addresses the issue raised here https://reviews.llvm.org/rG02bf5632a94da6c3570df002804f8d3f79c11bfc The `finish_swig_python` function might be called more than once so we need to create the distribution component target based on the swig target. Differential Revision: https://reviews.llvm.org/D86402
2020-08-22 11:53:08 -07:00
finish_swig_python("lldb-python" "${lldb_python_bindings_dir}" "${lldb_python_target_dir}")
[lldb] Move finish_swig logic into a function in the binding dir Move the finish_swig logic into a function in the bindings directory. By making this a function I can reuse the logic internally where we ship two Python versions and therefore need to finish the bindings twice.
2020-07-29 17:56:38 -07:00
endif()
[lldb/lua] Supplement Lua bindings for lldb module Add necessary typemaps for Lua bindings, together with some other files. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela Differential Revision: https://reviews.llvm.org/D108090
2021-10-12 22:08:05 +08:00
if (LLDB_ENABLE_LUA)
if(LLDB_BUILD_FRAMEWORK)
set(lldb_lua_target_dir "${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/Resources/Lua")
else()
set(lldb_lua_target_dir "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_LUA_RELATIVE_PATH}")
endif()
get_target_property(lldb_lua_bindings_dir swig_wrapper_lua BINARY_DIR)
finish_swig_lua("lldb-lua" "${lldb_lua_bindings_dir}" "${lldb_lua_target_dir}")
endif()
lldb: Disable unittests if llvm_gtest target does not exist This fixes the stand-alone build configuration where LLVM_MAIN_SRC_DIR does not exist. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D124314
2022-08-10 16:56:05 -07:00
set(LLDB_INCLUDE_UNITTESTS ON)
if (NOT TARGET llvm_gtest)
set(LLDB_INCLUDE_UNITTESTS OFF)
endif()
[CMake] Add LLDB_INCLUDE_TESTS variable This behaves like the other *_INCLUDE_TESTS variables in CMake and is tied to LLVM_INCLUDE_TESTS so that if you're building in-tree and not building the LLVM tests, you also won't build the LLDB tests. llvm-svn: 315120
2017-10-06 22:21:36 +00:00
if(LLDB_INCLUDE_TESTS)
add_subdirectory(test)
lldb: Disable unittests if llvm_gtest target does not exist This fixes the stand-alone build configuration where LLVM_MAIN_SRC_DIR does not exist. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D124314
2022-08-10 16:56:05 -07:00
if (LLDB_INCLUDE_UNITTESTS)
add_subdirectory(unittests)
endif()
[lldb/Cmake] Add a CMakeLists.txt to the utils directory... ... and include it from the main CMakeLists.txt instead of including the utility subdirectories directly. This is consistent with the other subdirectories and limits the scope of future changes.
2020-01-16 22:30:03 -08:00
add_subdirectory(utils)
[CMake] Add LLDB_INCLUDE_TESTS variable This behaves like the other *_INCLUDE_TESTS variables in CMake and is tied to LLVM_INCLUDE_TESTS so that if you're building in-tree and not building the LLVM tests, you also won't build the LLDB tests. llvm-svn: 315120
2017-10-06 22:21:36 +00:00
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-17 22:20:29 +00: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-18 16:44:45 +00: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 11:09:11 +00:00
llvm_distribution_add_targets()
endif()
Reference in New Issue Copy Permalink