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

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

108 lines
3.3 KiB
CMake
Raw Normal View History

[CMake] Bump CMake minimum version to 3.13.4 This upgrade should be friction-less because we've already been ensuring that CMake >= 3.13.4 is used. This is part of the effort discussed on llvm-dev here: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html Differential Revision: https://reviews.llvm.org/D78648
2020-04-22 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
Standalone cmake build improvements (bug #23889) patch by Eugene Zelenko. llvm-svn: 242529
2015-07-17 23:50:48 +08:00
Set cmake policy CMP0075 to NEW Summary: The policy is about cmake_include_files ignoring CMAKE_REQUIRED_LIBRARIES in the OLD behavior. Llvm already sets this policy to NEW, but that is overridden by our cmake_minimum_required command. This makes our cmake policy setup consistent with the llvm build files and avoids a warning when using newer versions of cmake. Reviewers: sgraenitz, xiaobai Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58279 llvm-svn: 354251
2019-02-18 18:09:29 +08:00
if(POLICY CMP0075)
cmake_policy(SET CMP0075 NEW)
endif()
Added a dot at the end of comment Summary: to test SVN commit access with a simple change. Reviewers: jankratochvil Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62243 llvm-svn: 361383
2019-05-22 21:23:15 +08:00
# Add path for custom modules.
[CMake] Abstract Config.h generation for Xcode This patch abstracts the generation of Config.h and creates a dummy project entry point to allow generation of LLDB's Config header without performing a full CMake configuration. This will enable the Xcode project to generate LLDB's Config header. llvm-svn: 301553
2017-04-28 00:04:26 +08:00
set(CMAKE_MODULE_PATH
${CMAKE_MODULE_PATH}
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
)
[CMake] Move standalone check so we don't have to reconfigure LLDB By moving the standalone check into the main CMake file, the whole file is ignored in a regular (non-standalone) build. This means that you can make changes to LLDBStandalone.cmake without having to reconfigure a build in a different directory. This matters when you share one source repository with different build directories (e.g. release-assert, debug, standalone). Differential revision: https://reviews.llvm.org/D64824 llvm-svn: 366346
2019-07-18 00:47:02 +08:00
# If we are not building as part of LLVM, build LLDB as a standalone project,
# using LLVM as an external library.
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
[CMake] Move project() call to main CMake file Summary: The main CMake file don't have a project() call. In this case, cmake will run a dummy project(Project ) at the very beginning. Even before cmake_minimum_required. And a series of compiler detections will be triggered. This is problematic if we depends on some policy to be set. E.g. CMP0056. try_compile will fail before we have a chance to do anything. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65362 llvm-svn: 367273
2019-07-30 07:09:31 +08:00
project(lldb)
[CMake] Move standalone check so we don't have to reconfigure LLDB By moving the standalone check into the main CMake file, the whole file is ignored in a regular (non-standalone) build. This means that you can make changes to LLDBStandalone.cmake without having to reconfigure a build in a different directory. This matters when you share one source repository with different build directories (e.g. release-assert, debug, standalone). Differential revision: https://reviews.llvm.org/D64824 llvm-svn: 366346
2019-07-18 00:47:02 +08:00
include(LLDBStandalone)
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 23:24:10 +08:00
set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to")
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_CXX_EXTENSIONS NO)
[CMake] Move standalone check so we don't have to reconfigure LLDB By moving the standalone check into the main CMake file, the whole file is ignored in a regular (non-standalone) build. This means that you can make changes to LLDBStandalone.cmake without having to reconfigure a build in a different directory. This matters when you share one source repository with different build directories (e.g. release-assert, debug, standalone). Differential revision: https://reviews.llvm.org/D64824 llvm-svn: 366346
2019-07-18 00:47:02 +08:00
endif()
[CMake] Abstract Config.h generation for Xcode This patch abstracts the generation of Config.h and creates a dummy project entry point to allow generation of LLDB's Config header without performing a full CMake configuration. This will enable the Xcode project to generate LLDB's Config header. llvm-svn: 301553
2017-04-28 00:04:26 +08:00
include(LLDBConfig)
include(AddLLDB)
Cmake build changes. Disables exception handling in LLDB, using appropriate compiler flags depending on the platform. This is consistent with the build of LLVM, should improve performance, and also removes a substantial number of warnings from the Windows build. See http://reviews.llvm.org/D3929 for more details. Change by Zachary Turner llvm-svn: 209752
2014-05-29 01:06:04 +08:00
Added a dot at the end of comment Summary: to test SVN commit access with a simple change. Reviewers: jankratochvil Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62243 llvm-svn: 361383
2019-05-22 21:23:15 +08:00
# Define the LLDB_CONFIGURATION_xxx matching the build type.
LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type Neither LLDB_CONFIGURATION_DEBUG nor LLDB_CONFIGURATION_RELEASE were ever set in the CMake LLDB project. Also cleaned up a questionable #ifdef in SharingPtr.h, removing all the references to LLDB_CONFIGURATION_BUILD_AND_INTEGRATION in the process. Differential Revision: https://reviews.llvm.org/D38552 llvm-svn: 314929
2017-10-05 04:23:56 +08:00
if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
add_definitions( -DLLDB_CONFIGURATION_DEBUG )
else()
add_definitions( -DLLDB_CONFIGURATION_RELEASE )
endif()
[CMake] Enable OS_LOG support on Darwin This gets CMake to match the Xcode project build llvm-svn: 309393
2017-07-28 23:39:50 +08:00
if(APPLE)
add_definitions(-DLLDB_USE_OS_LOG)
endif()
Define _ENABLE_EXTENDED_ALIGNED_STORAGE on Windows. Apparently there are multiple places where MSVC complains about instantiations with extended aligment. I think it's better to define `_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message. I don't have access to a Windows machine so this is all speculative. llvm-svn: 353778
2019-02-12 08:30:21 +08:00
if (WIN32)
add_definitions(-D_ENABLE_EXTENDED_ALIGNED_STORAGE)
endif()
[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)
[lldb] Unifying lldb python path Based on mgorny@'s D67890 There are 3 places where python site-package path is calculated independently: 1. finishSwigPythonLLDB.py where files are written to site-packages. 2. lldb/scripts/CMakeLists.txt where site-packages are installed. 3. ScriptInterpreterPython.cpp where site-packages are added to PYTHONPATH. This change creates the path once and use it everywhere. So that they will not go out of sync. Also it provides a chance for cross compiling users to specify the right path for site-packages. Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68442 llvm-svn: 373991
2019-10-08 07:49:01 +08:00
execute_process(
COMMAND ${PYTHON_EXECUTABLE}
python path should be platform-dependent Because one of the installed files is the _lldb.so symlink. Differential Revision: https://reviews.llvm.org/D68910
2019-10-16 03:24:37 +08:00
-c "import distutils.sysconfig; print(distutils.sysconfig.get_python_lib(True, False, ''))"
[lldb] Unifying lldb python path Based on mgorny@'s D67890 There are 3 places where python site-package path is calculated independently: 1. finishSwigPythonLLDB.py where files are written to site-packages. 2. lldb/scripts/CMakeLists.txt where site-packages are installed. 3. ScriptInterpreterPython.cpp where site-packages are added to PYTHONPATH. This change creates the path once and use it everywhere. So that they will not go out of sync. Also it provides a chance for cross compiling users to specify the right path for site-packages. Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68442 llvm-svn: 373991
2019-10-08 07:49:01 +08:00
OUTPUT_VARIABLE LLDB_PYTHON_DEFAULT_RELATIVE_PATH
OUTPUT_STRIP_TRAILING_WHITESPACE)
file(TO_CMAKE_PATH ${LLDB_PYTHON_DEFAULT_RELATIVE_PATH} LLDB_PYTHON_DEFAULT_RELATIVE_PATH)
set(LLDB_PYTHON_RELATIVE_PATH ${LLDB_PYTHON_DEFAULT_RELATIVE_PATH}
CACHE STRING "Path where Python modules are installed, relative to install prefix")
Fix Windows build when python is not explicitly enabled Currently Windows disables Python builds by default. This change ensures we don't process the scripts dir when we're on Windows unless we're explicitly enabling python, which prevents a build error. Change by Deepak Panickal llvm-svn: 212319
2014-07-04 14:43:47 +08:00
endif ()
[lldb] Let table gen create command option initializers. Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908
2019-07-12 23:30:55 +08:00
[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 16:01:09 +08: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 23: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 16:01:09 +08: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-09 07: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 15:29:53 +08: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-18 07:43:05 +08: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 15:29:53 +08:00
list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
endif()
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE)
set(LLVM_USE_HOST_TOOLS ON)
include(CrossCompile)
[cmake] Update NATIVE build variables to account for standalone changes Summary: LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64959 llvm-svn: 366513
2019-07-19 07:40:23 +08:00
if (NOT NATIVE_LLVM_DIR OR NOT NATIVE_Clang_DIR)
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
message(FATAL_ERROR
[cmake] Update NATIVE build variables to account for standalone changes Summary: LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64959 llvm-svn: 366513
2019-07-19 07:40:23 +08:00
"Crosscompiling standalone requires the variables NATIVE_{CLANG,LLVM}_DIR
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
for building the native lldb-tblgen used during the build process.")
endif()
llvm_create_cross_target(lldb NATIVE "" Release
[cmake] Update NATIVE build variables to account for standalone changes Summary: LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64959 llvm-svn: 366513
2019-07-19 07:40:23 +08:00
-DLLVM_DIR=${NATIVE_LLVM_DIR}
-DClang_DIR=${NATIVE_Clang_DIR})
[cmake] Add NATIVE build for cross compiling standalone builds TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
2019-07-18 08:21:57 +08:00
endif()
[TableGen] Move interpreter properties into a separate file (NFC) With the plugins having their own tablgen file, it makes sense to split off the interpreter properties as well. llvm-svn: 367138
2019-07-27 02:14:04 +08:00
# TableGen
[lldb] Let table gen create command option initializers. Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908
2019-07-12 23:30:55 +08:00
add_subdirectory(utils/TableGen)
[TableGen] Move interpreter properties into a separate file (NFC) With the plugins having their own tablgen file, it makes sense to split off the interpreter properties as well. llvm-svn: 367138
2019-07-27 02:14:04 +08:00
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(source)
add_subdirectory(tools)
[Docs] Generate the python reference without building all of LLDB As discussed on the mailing list, we should be able to generate the Python reference without building all of LLDB. To make that possible I create a dummy python package, which is then parsed by epydoc. The latter will complain that it couldn't import lldb, but that doesn't matter as far as generation of the docs is concerned. Differential revision: https://reviews.llvm.org/D61216 llvm-svn: 359465
2019-04-30 00:29:10 +08:00
add_subdirectory(docs)
[CMake] Add LLDB_INCLUDE_TESTS variable This behaves like the other *_INCLUDE_TESTS variables in CMake and is tied to LLVM_INCLUDE_TESTS so that if you're building in-tree and not building the LLVM tests, you also won't build the LLDB tests. llvm-svn: 315120
2017-10-07 06:21:36 +08:00
[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-30 08:56:38 +08:00
if (LLDB_ENABLE_PYTHON OR LLDB_ENABLE_LUA)
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()
get_target_property(lldb_bindings_dir swig_wrapper BINARY_DIR)
finish_swig("finish_swig" "${lldb_bindings_dir}" "${lldb_python_target_dir}")
endif()
[CMake] Include tests by default also in standalone builds In-tree builds include tests by default. Standalone builds should behave the same. llvm-svn: 350945
2019-01-12 02:11:04 +08:00
option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests." ${LLVM_INCLUDE_TESTS})
[CMake] Add LLDB_INCLUDE_TESTS variable This behaves like the other *_INCLUDE_TESTS variables in CMake and is tied to LLVM_INCLUDE_TESTS so that if you're building in-tree and not building the LLVM tests, you also won't build the LLDB tests. llvm-svn: 315120
2017-10-07 06:21:36 +08:00
if(LLDB_INCLUDE_TESTS)
add_subdirectory(test)
add_subdirectory(unittests)
[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-17 14: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-07 06:21:36 +08:00
endif()
[CMake] Create a custom target for generating extension module. Previously we would create the extension module as a post-build step of creating liblldb. As part of this process, we created symlinks and did other stuff. This had several longstanding issues related to target dependencies, such as not re-creating the symlink if liblldb.dll failed to link, or if the build was Ctrl+C'ed from. Then, the script that creates the symlinks began to grow to include other things, such as argdumper, and it would try to create symlinks before it had finished building the targets it needed to symlink to. This patches addresses all of these problems by creating an explicit target for the script to run, and making it have a dependency on all the targets it needs to create symlinks from/to. llvm-svn: 229569
2015-02-18 06:20:29 +08:00
[CMake] Polish folders in generated Xcode project Summary: Group plugins by subfolder. Move liblldb-resource-headers to `lldb misc`. Avoid install-distribution related targets in IDE-enabled builds. Reviewers: jingham, mib, stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64865 llvm-svn: 366459
2019-07-19 00:44:45 +08:00
if(LLDB_BUILT_STANDALONE AND NOT LLVM_ENABLE_IDE)
[CMake] Distribution builds for LLDB standalone Summary: Enable `distribution` and `install-distribution` targets in LLDB standalone and pre-populate the cache accordingly on macOS. Documentation for distribution builds is here: https://llvm.org/docs/BuildingADistribution.html Reviewers: xiaobai, mgorny, JDevlieghere, davide, compnerd Reviewed By: xiaobai, JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64399 llvm-svn: 365616
2019-07-10 19:09:11 +08:00
llvm_distribution_add_targets()
endif()