replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lldb/scripts/CMakeLists.txt

61 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)
Install lldb Python module on Windows. Patch by Vadim Chugunov Differential Revision: https://reviews.llvm.org/D27476 llvm-svn: 291291
2017-01-07 06:05:35 +08:00
if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
set(SWIG_PYTHON_DIR
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
else()
set(SWIG_PYTHON_DIR ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/site-packages)
endif()
[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_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
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
${framework_arg}
--srcRoot=${LLDB_SOURCE_DIR}
--targetDir=${LLDB_PYTHON_TARGET_DIR}
--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}
--prefix=${CMAKE_BINARY_DIR}
--swigExecutable=${SWIG_EXECUTABLE}
VERBATIM
[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
Install lldb Python module on Windows. Patch by Vadim Chugunov Differential Revision: https://reviews.llvm.org/D27476 llvm-svn: 291291
2017-01-07 06:05:35 +08:00
# Install the LLDB python module
install(DIRECTORY ${SWIG_PYTHON_DIR} DESTINATION ${SWIG_INSTALL_DIR})
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)