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

57 lines
2.2 KiB
CMake
Raw Normal View History

Start to share SWIG interface files between languages. Summary: Move scripts/Python/interface to scripts/interface so that we can start making iterative improvements towards sharing the interface files between multiple languages (each of which would have their own directory as now). Test Plan: Build and see. Reviewers: zturner, emaste, clayborg Reviewed By: clayborg Subscribers: mjsabby, lldb-commits Differential Revision: http://reviews.llvm.org/D9212 llvm-svn: 235676
2015-04-24 08:38:53 +08:00
file(GLOB SWIG_INTERFACES interface/*.i)
[CMake] Make LLDBWrapPython.cpp depend on the .swig files. Previously it would only regenerate LLDBWrapPython.cpp if one of the .i files changed, or if lldb.swig changed. This patch also makes it depend on the rest of the *.swig files, so that if any of them changes it regenerates the CMake. llvm-svn: 232175
2015-03-14 00:31:58 +08:00
file(GLOB_RECURSE SWIG_SOURCES *.swig)
Add explicit dependency on headers to swig wrapper (cmake build) This should avoid issues like that described in llvm.org/pr23686 Differential Revision: http://reviews.llvm.org/D10092 llvm-svn: 238441
2015-05-29 01:25:34 +08:00
set(SWIG_HEADERS
${LLDB_SOURCE_DIR}/include/lldb/API/SBDefines.h
${LLDB_SOURCE_DIR}/include/lldb/lldb-defines.h
${LLDB_SOURCE_DIR}/include/lldb/lldb-enumerations.h
${LLDB_SOURCE_DIR}/include/lldb/lldb-forward.h
${LLDB_SOURCE_DIR}/include/lldb/lldb-types.h
${LLDB_SOURCE_DIR}/include/lldb/lldb-versioning.h
)
Add explict dependencies on swig .i files for cmake builds llvm.org/pr19316 llvm-svn: 205539
2014-04-03 23:03:11 +08:00
Add CMake bits necessary for standalone build Summary: Developed on NetBSD with pkgsrc. Reviewers: zturner, labath Subscribers: jevinskie, zturner, tfiala, Eugene.Zelenko, artagnon, joerg, lldb-commits Differential Revision: http://reviews.llvm.org/D15067 llvm-svn: 269332
2016-05-13 03:49:17 +08:00
include(FindPythonInterp)
[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(SWIG_PYTHON_DIR
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
set(SWIG_INSTALL_DIR lib${LLVM_LIBDIR_SUFFIX})
# Generating the LLDB framework correctly is a bit complicated because the
# framework depends on the swig output.
if(LLDB_BUILD_FRAMEWORK)
set(framework_arg --framework --target-platform Darwin)
set(SWIG_PYTHON_DIR
${LLDB_PYTHON_TARGET_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR}/Python)
set(SWIG_INSTALL_DIR
${LLDB_FRAMEWORK_INSTALL_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR})
endif()
[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
find_package(SWIG REQUIRED)
add_custom_command(
[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
OUTPUT ${LLDB_WRAP_PYTHON}
Symlink the `six` module during swig generation. llvm-svn: 252764
2015-11-12 01:59:34 +08:00
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
[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
DEPENDS ${SWIG_SOURCES}
DEPENDS ${SWIG_INTERFACES}
DEPENDS ${SWIG_HEADERS}
Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes This closes: http://reviews.llvm.org/D14783 llvm-svn: 253513
2015-11-19 06:21:47 +08:00
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/prepare_binding_Python.py
Python 3 - Use __bool__() instead of __nonzero__() for truthiness. Python has a complicated mechanism of checking an objects truthity. This involves a number of steps, which end with calling two private methods on an object (if they are implemented). In Python 2 these two methods are `__nonzero__` and `__len__`, and in Python 3 they are `__bool__` and `__len__`. Because we *also* define a __len__ method for certain iterable types, this was triggering a situation in Python 3 where `__nonzero__` wasn't defined, so it was calling `__len__`, which was returning 0 (for example an SBDebugger with no targets), and as a result the truthosity was determined to be False. We fix this by correctly using ` __bool__` for Python 3, and leave the behavior under Python 2 unchanged. Note that this fix is only implemented in the SWIG generation python script, and not the SWIG generation shell script. Someone more familiar than me with shell scripts will need to fix them to support this for Python 3 if desired. llvm-svn: 252382
2015-11-07 09:08:25 +08:00
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
[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
COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
${framework_arg}
"--srcRoot=${LLDB_SOURCE_DIR}"
"--targetDir=${LLDB_PYTHON_TARGET_DIR}"
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}"
"--prefix=${CMAKE_BINARY_DIR}"
"--swigExecutable=${SWIG_EXECUTABLE}"
[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
COMMENT "Python script building LLDB Python wrapper")
[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_source_files_properties(${LLDB_WRAP_PYTHON} PROPERTIES GENERATED 1)
Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version. This change does not introduce static bindings. It is simply using the pylinted cleaned up code in prepare_bindings.py. If this breaks anyting, I'll revert immediately and figure out what needs to be addressed. I'm looking to wrap up the cleanup aspect of the code change (pylinted, removal of code that implements existing python stdlib code, fixes for Xcode adoption, etc.). llvm-svn: 253478
2015-11-19 01:36:15 +08:00
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py PROPERTIES GENERATED 1)
Remove the windows CR llvm-svn: 183911
2013-06-14 00:05:41 +08:00
[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
add_custom_target(swig_wrapper ALL DEPENDS ${LLDB_WRAP_PYTHON})
Remove the windows CR llvm-svn: 183911
2013-06-14 00:05:41 +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
# Install the LLDB python module on all operating systems (except Windows)
if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
[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
install(DIRECTORY ${SWIG_PYTHON_DIR} DESTINATION ${SWIG_INSTALL_DIR})
[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
endif()
Suppress python readline module under Linux to fix a seg fault. Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
2014-02-26 15:39:20 +08:00
# build Python modules
Fix the Windows build by removing the unused lldb_python_module.cmake inclusion from CMakeLists. llvm-svn: 216392
2014-08-26 02:16:22 +08:00
add_subdirectory(Python/modules)