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

89 lines
3.4 KiB
CMake
Raw Normal View History

[CMake] Update to requiring CMake 3.4.3 Summary: This is as per the discussions on developer lists: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098780.html http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20826 llvm-svn: 271328
2016-06-01 04:21:44 +08:00
cmake_minimum_required(VERSION 3.4.3)
Standalone cmake build improvements (bug #23889) patch by Eugene Zelenko. llvm-svn: 242529
2015-07-17 23:50:48 +08:00
[CMake] Refactor LLDB main CMake file. The existing state of affairs was getting a little unwieldy. All of LLDB's utility functions and initial configuration was in the root CMake file. I split this up into 3 separate files and moved them to relevant subfolders under cmake/modules. Also, I deleted the add_lldb_definitions() function. It seemed to be somewhat useless and did not serve any real purpose that I was able to figure out. llvm-svn: 231010
2015-03-03 04:45:26 +08:00
include(cmake/modules/LLDBStandalone.cmake)
Standalone cmake build improvements (bug #23889) patch by Eugene Zelenko. llvm-svn: 242529
2015-07-17 23:50:48 +08:00
include(cmake/modules/LLDBConfig.cmake)
[CMake] Refactor LLDB main CMake file. The existing state of affairs was getting a little unwieldy. All of LLDB's utility functions and initial configuration was in the root CMake file. I split this up into 3 separate files and moved them to relevant subfolders under cmake/modules. Also, I deleted the add_lldb_definitions() function. It seemed to be somewhat useless and did not serve any real purpose that I was able to figure out. llvm-svn: 231010
2015-03-03 04:45:26 +08:00
include(cmake/modules/AddLLDB.cmake)
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
[cmake] Make lldb build with the android ndk toolchain file Summary: The NDK cmake toolchain file defines CMAKE_SYSTEM_NAME=Android, so switch the build to use that. I have also updated the in-tree toolchain file to do that (instead of defining __ANDROID_NDK__), so it can still be used to build. After migrating the last bits of non-toolchainy bits out of the in-tree toolchain, I intend to delete it. Reviewers: tberghammer, danalbert Subscribers: srhines, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D28775 llvm-svn: 292212
2017-01-17 19:55:00 +08:00
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
Fix Android build. llvm-svn: 249486
2015-10-07 08:01:06 +08:00
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
set(LLDB_DEFAULT_DISABLE_LIBEDIT 0)
endif ()
Simple readline functionality for interactive python on linux. Differential Revision: http://reviews.llvm.org/D13268 llvm-svn: 249478
2015-10-07 06:21:08 +08:00
# We need libedit support to go down both the source and
# the scripts directories.
set(LLDB_DISABLE_LIBEDIT ${LLDB_DEFAULT_DISABLE_LIBEDIT} CACHE BOOL "Disables the use of editline.")
if (LLDB_DISABLE_LIBEDIT)
add_definitions( -DLLDB_DISABLE_LIBEDIT )
endif()
# add_subdirectory(include)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(docs)
Remove check for windows when compiling scripts directory this is a followup to r234319, change requested in http://reviews.llvm.org/D8855. llvm-svn: 234321
2015-04-07 23:30:23 +08:00
if (NOT LLDB_DISABLE_PYTHON)
[CMake] Initial support for LLDB.framework Summary: This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library. With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow. The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step. With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up. Reviewers: zturner, tfiala Subscribers: beanz, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D24749 llvm-svn: 282110
2016-09-22 05:02:16 +08:00
set(LLDB_PYTHON_TARGET_DIR ${LLDB_BINARY_DIR}/scripts)
if(LLDB_BUILD_FRAMEWORK)
set(LLDB_PYTHON_TARGET_DIR
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_FRAMEWORK_INSTALL_DIR})
else()
# Don't set -m when building the framework.
set(FINISH_EXTRA_ARGS "-m")
endif()
[CMake] Fix finding LLDBWrapPython.cpp in Framework build The framework build was constructing the path to LLDBWrapPython incorrectly. It is apparently always in the scripts directory. llvm-svn: 291788
2017-01-13 02:45:59 +08:00
set(LLDB_WRAP_PYTHON ${LLDB_BINARY_DIR}/scripts/LLDBWrapPython.cpp)
[CMake] Initial support for LLDB.framework Summary: This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library. With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow. The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step. With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up. Reviewers: zturner, tfiala Subscribers: beanz, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D24749 llvm-svn: 282110
2016-09-22 05:02:16 +08:00
Fix Windows build when python is not explicitly enabled Currently Windows disables Python builds by default. This change ensures we don't process the scripts dir when we're on Windows unless we're explicitly enabling python, which prevents a build error. Change by Deepak Panickal llvm-svn: 212319
2014-07-04 14:43:47 +08:00
add_subdirectory(scripts)
endif ()
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(source)
add_subdirectory(test)
add_subdirectory(tools)
Rework the gtest directory structure. This makes the directory structure mirror the canonical LLVM directory structure for a gtest suite. Additionally, this patch deletes the xcode project. Nobody is currently depending on this, and it would be better to have gtest unit tests be hand-maintained in the Xcode workspace rather than using this python test runner. Patches to that effect will be submitted as followups. llvm-svn: 232211
2015-03-14 04:54:57 +08:00
add_subdirectory(unittests)
Create a check-lldb-unit target to run unit tests. llvm-svn: 232212
2015-03-14 04:55:07 +08:00
add_subdirectory(lit)
[CMake] Create a custom target for generating extension module. Previously we would create the extension module as a post-build step of creating liblldb. As part of this process, we created symlinks and did other stuff. This had several longstanding issues related to target dependencies, such as not re-creating the symlink if liblldb.dll failed to link, or if the build was Ctrl+C'ed from. Then, the script that creates the symlinks began to grow to include other things, such as argdumper, and it would try to create symlinks before it had finished building the targets it needed to symlink to. This patches addresses all of these problems by creating an explicit target for the script to run, and making it have a dependency on all the targets it needs to create symlinks from/to. llvm-svn: 229569
2015-02-18 06:20:29 +08:00
[cmake] Remove LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION. Summary: This should be a mandatory build process going forward, if Python is enabled. The longer term desire is to remove the old shell scripts entirely. Reviewers: zturner, clayborg, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12667 llvm-svn: 246979
2015-09-08 13:00:22 +08:00
if (NOT LLDB_DISABLE_PYTHON)
Fix broken escaping of commands in the build A combination of broken escaping in CMake and in the python swig generation scripts meant that the swig generation step would fail whenever there were spaces or special characters in parameters passed to swig. The fix for this in CMakeLists is to use the VERBATIM option on all COMMAND-based custom builders relying on CMake to properly escape each argument in the generated file. Within the python swig scripts, the fix is to call subprocess.Popen with a list of raw argument strings rather than ones that are incorrectly manually escaped, then passed to a shell subprocess via subprocess.Popen(' '.join(params)). This also prevents nasty things happening such as accidental command-injection. This allows us to have the swig / python executables in paths containing special chars and spaces, (or on shared storage on Win32, e.g \\some\path or C:\Program Files\swig\swig.exe). Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26757 llvm-svn: 289956
2016-12-17 00:38:25 +08:00
# Add a Post-Build Event to copy over Python files and create the symlink
# to liblldb.so for the Python API(hardlink on Windows)
add_custom_target(finish_swig ALL
COMMAND
${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
--srcRoot=${LLDB_SOURCE_DIR}
--targetDir=${LLDB_PYTHON_TARGET_DIR}
--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts
--prefix=${CMAKE_BINARY_DIR}
--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}
--lldbLibDir=lib${LLVM_LIBDIR_SUFFIX}
${FINISH_EXTRA_ARGS}
VERBATIM
[CMake] Create a custom target for generating extension module. Previously we would create the extension module as a post-build step of creating liblldb. As part of this process, we created symlinks and did other stuff. This had several longstanding issues related to target dependencies, such as not re-creating the symlink if liblldb.dll failed to link, or if the build was Ctrl+C'ed from. Then, the script that creates the symlinks began to grow to include other things, such as argdumper, and it would try to create symlinks before it had finished building the targets it needed to symlink to. This patches addresses all of these problems by creating an explicit target for the script to run, and making it have a dependency on all the targets it needs to create symlinks from/to. llvm-svn: 229569
2015-02-18 06:20:29 +08:00
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
Fix CMake dependency on lldb.py llvm-svn: 253501
2015-11-19 05:09:55 +08:00
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/scripts/lldb.py
[CMake] Create a custom target for generating extension module. Previously we would create the extension module as a post-build step of creating liblldb. As part of this process, we created symlinks and did other stuff. This had several longstanding issues related to target dependencies, such as not re-creating the symlink if liblldb.dll failed to link, or if the build was Ctrl+C'ed from. Then, the script that creates the symlinks began to grow to include other things, such as argdumper, and it would try to create symlinks before it had finished building the targets it needed to symlink to. This patches addresses all of these problems by creating an explicit target for the script to run, and making it have a dependency on all the targets it needs to create symlinks from/to. llvm-svn: 229569
2015-02-18 06:20:29 +08:00
COMMENT "Python script sym-linking LLDB Python API")
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
# We depend on liblldb being built before we can do this step.
Fixup lldb-argdumper cmake build forgot to rename in one spot. llvm-svn: 251628
2015-10-29 22:14:24 +08:00
add_dependencies(finish_swig liblldb lldb-argdumper)
cmake fixes for lldb target. ninja lldb now does the following: * forces the python post-build step to fire, which sets up the python lldb module properly. * on Darwin and Linux, requires the lldb-server target to be built. * on Darwin, requires the debugserver target to be built. See http://reviews.llvm.org/D12899 for details. llvm-svn: 247810
2015-09-16 23:34:06 +08:00
cmake: ensure readline python module target is added before finishing swig. When the readline target exists (only for non-Android Linux currently), ensure that target is made a dependency of the finish_swig python-wrap-up steps. This ensures it is built when building the lldb target. Fixes: https://llvm.org/bugs/show_bug.cgi?id=25038 llvm-svn: 249256
2015-10-04 09:28:51 +08:00
# If we build the readline module, we depend on that happening
# first.
if (TARGET readline)
add_dependencies(finish_swig readline)
endif()
cmake fixes for lldb target. ninja lldb now does the following: * forces the python post-build step to fire, which sets up the python lldb module properly. * on Darwin and Linux, requires the lldb-server target to be built. * on Darwin, requires the debugserver target to be built. See http://reviews.llvm.org/D12899 for details. llvm-svn: 247810
2015-09-16 23:34:06 +08:00
# Ensure we do the python post-build step when building lldb.
add_dependencies(lldb finish_swig)
Add a Post-Build Event on Windows to copy the correct custom Python DLL to the LLDB binaries dir Summary: After a developer builds LLDB from source on Windows (assuming they've built it with Python support enabled), they may be somewhat flustered when it fails to launch with a cryptic error. {F890625} This happens because Windows can't find python27.dll (or python27_d.dll in case LLDB was built in debug mode). Many developers may have previously installed a release build of Python 2.7 and will not notice anything is amiss when they run a release build of LLDB because Windows will load the python27.dll from one of the system directories or `PATH` (rather than the one that the LLDB build instructions tell them to build). The issue tends to be more pronounced with debug builds of LLDB, since fewer developers probably have python27_d.dll sitting in one of the Windows system directories. To ensure Windows loads the correct custom built Python DLL when launching LLDB I've added a post-build event that copies the relevant DLL (based on the LLDB build configuration) from `PYTHON_HOME` to the directory in which the LLDB executable is generated. Patch by Vadim Macagon. Thanks! Reviewers: brucem, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13237 llvm-svn: 248992
2015-10-01 15:55:44 +08:00
[CMake] Ensure Python files are inside the LLDB framework bundle When building the LLDB Framework we need to ensure that the Python files get put into the Framework before the Framework's install target can be invoked. All files inside the Framework's Resources bundle will get copied over during the install action. llvm-svn: 289842
2016-12-16 02:19:10 +08:00
if(LLDB_BUILD_FRAMEWORK)
# The target to install libLLDB needs to depend on finish swig so that the
# framework build properly copies over the Python files.
add_dependencies(install-liblldb finish_swig)
endif()
Add a Post-Build Event on Windows to copy the correct custom Python DLL to the LLDB binaries dir Summary: After a developer builds LLDB from source on Windows (assuming they've built it with Python support enabled), they may be somewhat flustered when it fails to launch with a cryptic error. {F890625} This happens because Windows can't find python27.dll (or python27_d.dll in case LLDB was built in debug mode). Many developers may have previously installed a release build of Python 2.7 and will not notice anything is amiss when they run a release build of LLDB because Windows will load the python27.dll from one of the system directories or `PATH` (rather than the one that the LLDB build instructions tell them to build). The issue tends to be more pronounced with debug builds of LLDB, since fewer developers probably have python27_d.dll sitting in one of the Windows system directories. To ensure Windows loads the correct custom built Python DLL when launching LLDB I've added a post-build event that copies the relevant DLL (based on the LLDB build configuration) from `PYTHON_HOME` to the directory in which the LLDB executable is generated. Patch by Vadim Macagon. Thanks! Reviewers: brucem, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13237 llvm-svn: 248992
2015-10-01 15:55:44 +08:00
# Add a Post-Build Event to copy the custom Python DLL to the lldb binaries dir so that Windows can find it when launching
# lldb.exe or any other executables that were linked with liblldb.
if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
# When using the Visual Studio CMake generator the lldb binaries end up in Release/bin, Debug/bin etc.
file(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin" LLDB_BIN_DIR)
file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
add_custom_command(
TARGET finish_swig
POST_BUILD
Fix broken escaping of commands in the build A combination of broken escaping in CMake and in the python swig generation scripts meant that the swig generation step would fail whenever there were spaces or special characters in parameters passed to swig. The fix for this in CMakeLists is to use the VERBATIM option on all COMMAND-based custom builders relying on CMake to properly escape each argument in the generated file. Within the python swig scripts, the fix is to call subprocess.Popen with a list of raw argument strings rather than ones that are incorrectly manually escaped, then passed to a shell subprocess via subprocess.Popen(' '.join(params)). This also prevents nasty things happening such as accidental command-injection. This allows us to have the swig / python executables in paths containing special chars and spaces, (or on shared storage on Win32, e.g \\some\path or C:\Program Files\swig\swig.exe). Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26757 llvm-svn: 289956
2016-12-17 00:38:25 +08:00
COMMAND ${CMAKE_COMMAND} -E copy ${PYTHON_DLL_NATIVE_PATH} ${LLDB_BIN_DIR} VERBATIM
Add a Post-Build Event on Windows to copy the correct custom Python DLL to the LLDB binaries dir Summary: After a developer builds LLDB from source on Windows (assuming they've built it with Python support enabled), they may be somewhat flustered when it fails to launch with a cryptic error. {F890625} This happens because Windows can't find python27.dll (or python27_d.dll in case LLDB was built in debug mode). Many developers may have previously installed a release build of Python 2.7 and will not notice anything is amiss when they run a release build of LLDB because Windows will load the python27.dll from one of the system directories or `PATH` (rather than the one that the LLDB build instructions tell them to build). The issue tends to be more pronounced with debug builds of LLDB, since fewer developers probably have python27_d.dll sitting in one of the Windows system directories. To ensure Windows loads the correct custom built Python DLL when launching LLDB I've added a post-build event that copies the relevant DLL (based on the LLDB build configuration) from `PYTHON_HOME` to the directory in which the LLDB executable is generated. Patch by Vadim Macagon. Thanks! Reviewers: brucem, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13237 llvm-svn: 248992
2015-10-01 15:55:44 +08:00
COMMENT "Copying Python DLL to LLDB binaries directory.")
endif ()
[CMake] Create a custom target for generating extension module. Previously we would create the extension module as a post-build step of creating liblldb. As part of this process, we created symlinks and did other stuff. This had several longstanding issues related to target dependencies, such as not re-creating the symlink if liblldb.dll failed to link, or if the build was Ctrl+C'ed from. Then, the script that creates the symlinks began to grow to include other things, such as argdumper, and it would try to create symlinks before it had finished building the targets it needed to symlink to. This patches addresses all of these problems by creating an explicit target for the script to run, and making it have a dependency on all the targets it needs to create symlinks from/to. llvm-svn: 229569
2015-02-18 06:20:29 +08:00
endif ()