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

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

49 lines
1.3 KiB
CMake
Raw Normal View History

[Driver] Use libOption with tablegen. This patch modifies the lldb driver to use libOption for option parsing. It allows us to decouple option parsing from option processing which is important when arguments affect initialization. This was previously not possible because the debugger need to be initialized as some option interpretation (like the scripting language etc) was handled by the debugger, rather than in the driver. Differential revision: https://reviews.llvm.org/D54692 llvm-svn: 347709
2018-11-28 05:00:32 +08:00
set(LLVM_TARGET_DEFINITIONS Options.td)
tablegen(LLVM Options.inc -gen-opt-parser-defs)
add_public_tablegen_target(LLDBOptionsTableGen)
[CMake] Inline info plist in lldb driver llvm-svn: 361068
2019-05-18 03:19:34 +08:00
if(APPLE)
[CMake] Configure the Info.plist so it contains a real version number. Use CMake to configure the Info.plist file so that we have a real version number in things like crash reporter.
2019-11-16 01:46:27 +08:00
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/lldb-Info.plist.in
${CMAKE_CURRENT_BINARY_DIR}/lldb-Info.plist
)
[CMake] Inline info plist in lldb driver llvm-svn: 361068
2019-05-18 03:19:34 +08:00
# Inline info plist in binary (use target_link_options for this as soon as CMake 3.13 is available)
[CMake] Configure the Info.plist so it contains a real version number. Use CMake to configure the Info.plist file so that we have a real version number in things like crash reporter.
2019-11-16 01:46:27 +08:00
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-sectcreate,__TEXT,__info_plist,${CMAKE_CURRENT_BINARY_DIR}/lldb-Info.plist")
[CMake] Inline info plist in lldb driver llvm-svn: 361068
2019-05-18 03:19:34 +08:00
endif()
[CMake] Refactor LLDB libraries and tools to be components In LLVM's CMake we have a convention that components have both a build and an install target. Making LLDB follow this convention will allow LLDB to take advantage of the LLVM_DISTRIBUTION_COMPONENTS build option from LLVM. llvm-svn: 289879
2016-12-16 06:01:17 +08:00
add_lldb_tool(lldb
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
Driver.cpp
Patch enabling lldb command line driver to run on windows. CHANGES: - Thread locking switched from pthreads to C++11 standard library. - Abstracted platform specific header includes into 'platform.h'. - Create editline emulator for windows. - Emulated various platform dependant functions on windows. TODO: - User input currently handled by gets_s(), work started on better handler: see _WIP_INPUT_METHOD define blocks in 'ELWrapper.cpp'. Aim is to handle 'tab' auto completion on windows. - Tidy up 'getopt.inc' from lldbHostCommon to serve as LLDB Drivers getopt windows implementation. llvm-svn: 192714
2013-10-15 23:46:40 +08:00
Platform.cpp
[CMake] Add accurate dependency specifications Summary: This patch adds accurate dependency specifications to the mail LLDB libraries and tools. In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way. For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up. Reviewers: labath, zturner Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell Differential Revision: https://reviews.llvm.org/D29333 llvm-svn: 293686
2017-02-01 04:43:05 +08:00
LINK_LIBS
liblldb
LINK_COMPONENTS
[Driver] Use libOption with tablegen. This patch modifies the lldb driver to use libOption for option parsing. It allows us to decouple option parsing from option processing which is important when arguments affect initialization. This was previously not possible because the debugger need to be initialized as some option interpretation (like the scripting language etc) was handled by the debugger, rather than in the driver. Differential revision: https://reviews.llvm.org/D54692 llvm-svn: 347709
2018-11-28 05:00:32 +08:00
Option
[CMake] Add accurate dependency specifications Summary: This patch adds accurate dependency specifications to the mail LLDB libraries and tools. In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way. For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up. Reviewers: labath, zturner Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell Differential Revision: https://reviews.llvm.org/D29333 llvm-svn: 293686
2017-02-01 04:43:05 +08:00
Support
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
)
Build liblldb.dll in Windows llvm-svn: 202724
2014-03-03 23:50:36 +08:00
if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
Resubmit "[CMake] Change lldbAPI to be a CMake OBJECT library." This resubmits r230380. The primary cause of the failure was actually just a warning, which we can disable at the CMake level in a followup patch on the LLVM side. The other thing which was actually an error on the bot should be able to be fixed with a clean. llvm-svn: 230389
2015-02-25 06:17:57 +08:00
add_definitions( -DIMPORT_LIBLLDB )
Build liblldb.dll in Windows llvm-svn: 202724
2014-03-03 23:50:36 +08:00
endif()
[Driver] Use libOption with tablegen. This patch modifies the lldb driver to use libOption for option parsing. It allows us to decouple option parsing from option processing which is important when arguments affect initialization. This was previously not possible because the debugger need to be initialized as some option interpretation (like the scripting language etc) was handled by the debugger, rather than in the driver. Differential revision: https://reviews.llvm.org/D54692 llvm-svn: 347709
2018-11-28 05:00:32 +08:00
add_dependencies(lldb
LLDBOptionsTableGen
${tablegen_deps}
)
[CMake] Revised RPATH handling Summary: If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling. * In the build-tree, tools use the absolute path to the framework's actual output location. * In the install-tree, tools get a list of RPATHs to look for the framework when deployed. `LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree. If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree). If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree. For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks". Reviewers: xiaobai, JDevlieghere, aprantl, clayborg Reviewed By: JDevlieghere Subscribers: ki.stfu, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55330 llvm-svn: 350392
2019-01-04 20:46:57 +08:00
[CMake] Folder structure for generated Xcode project to cover more targets llvm-svn: 361799
2019-05-28 17:29:05 +08:00
set_target_properties(LLDBOptionsTableGen PROPERTIES FOLDER "lldb misc")
[CMake] Revised RPATH handling Summary: If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling. * In the build-tree, tools use the absolute path to the framework's actual output location. * In the install-tree, tools get a list of RPATHs to look for the framework when deployed. `LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree. If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree). If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree. For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks". Reviewers: xiaobai, JDevlieghere, aprantl, clayborg Reviewed By: JDevlieghere Subscribers: ki.stfu, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55330 llvm-svn: 350392
2019-01-04 20:46:57 +08:00
if(LLDB_BUILD_FRAMEWORK)
[CMake] LLDB.framework tools handling Summary: Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach. No function change otherwise. This is a reduced follow-up from the proposal in D61952. Reviewers: xiaobai, compnerd, JDevlieghere Reviewed By: JDevlieghere Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D62472 llvm-svn: 361946
2019-05-29 19:26:06 +08:00
# In the build-tree, we know the exact path to the framework directory.
# The installed framework can be in different locations.
lldb_setup_rpaths(lldb
BUILD_RPATH
[lldb] Record framework build path and use it everywhere This avoids config time dependencies on liblldb. And enables other refactoring.
2019-10-31 01:33:05 +08:00
"${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}"
[CMake] LLDB.framework tools handling Summary: Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach. No function change otherwise. This is a reduced follow-up from the proposal in D61952. Reviewers: xiaobai, compnerd, JDevlieghere Reviewed By: JDevlieghere Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D62472 llvm-svn: 361946
2019-05-29 19:26:06 +08:00
INSTALL_RPATH
"@loader_path/../../../SharedFrameworks"
"@loader_path/../../System/Library/PrivateFrameworks"
"@loader_path/../../Library/PrivateFrameworks"
)
[CMake] Revised RPATH handling Summary: If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling. * In the build-tree, tools use the absolute path to the framework's actual output location. * In the install-tree, tools get a list of RPATHs to look for the framework when deployed. `LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree. If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree). If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree. For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks". Reviewers: xiaobai, JDevlieghere, aprantl, clayborg Reviewed By: JDevlieghere Subscribers: ki.stfu, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55330 llvm-svn: 350392
2019-01-04 20:46:57 +08:00
endif()