[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
|
|
|
function(lldb_tablegen)
|
|
|
|
# Syntax:
|
|
|
|
# lldb_tablegen output-file [tablegen-arg ...] SOURCE source-file
|
|
|
|
# [[TARGET cmake-target-name] [DEPENDS extra-dependency ...]]
|
|
|
|
#
|
|
|
|
# Generates a custom command for invoking tblgen as
|
|
|
|
#
|
|
|
|
# tblgen source-file -o=output-file tablegen-arg ...
|
|
|
|
#
|
|
|
|
# and, if cmake-target-name is provided, creates a custom target for
|
|
|
|
# executing the custom command depending on output-file. It is
|
|
|
|
# possible to list more files to depend after DEPENDS.
|
|
|
|
|
|
|
|
cmake_parse_arguments(LTG "" "SOURCE;TARGET" "" ${ARGN})
|
|
|
|
|
|
|
|
if(NOT LTG_SOURCE)
|
|
|
|
message(FATAL_ERROR "SOURCE source-file required by lldb_tablegen")
|
|
|
|
endif()
|
|
|
|
|
|
|
|
set(LLVM_TARGET_DEFINITIONS ${LTG_SOURCE})
|
|
|
|
tablegen(LLDB ${LTG_UNPARSED_ARGUMENTS})
|
|
|
|
|
|
|
|
if(LTG_TARGET)
|
|
|
|
add_public_tablegen_target(${LTG_TARGET})
|
|
|
|
set_target_properties( ${LTG_TARGET} PROPERTIES FOLDER "LLDB tablegenning")
|
|
|
|
set_property(GLOBAL APPEND PROPERTY LLDB_TABLEGEN_TARGETS ${LTG_TARGET})
|
|
|
|
endif()
|
|
|
|
endfunction(lldb_tablegen)
|
|
|
|
|
2016-12-16 06:01:17 +08:00
|
|
|
function(add_lldb_library name)
|
[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
|
|
|
include_directories(BEFORE
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}
|
|
|
|
)
|
|
|
|
|
2015-07-17 23:26:27 +08:00
|
|
|
# only supported parameters to this macro are the optional
|
2015-03-19 00:56:24 +08:00
|
|
|
# MODULE;SHARED;STATIC library type and source files
|
|
|
|
cmake_parse_arguments(PARAM
|
2019-11-13 06:15:06 +08:00
|
|
|
"MODULE;SHARED;STATIC;OBJECT;PLUGIN;FRAMEWORK"
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
"INSTALL_PREFIX;ENTITLEMENTS"
|
2019-10-04 20:03:03 +08:00
|
|
|
"EXTRA_CXXFLAGS;DEPENDS;LINK_LIBS;LINK_COMPONENTS;CLANG_LIBS"
|
2015-03-19 00:56:24 +08:00
|
|
|
${ARGN})
|
|
|
|
llvm_process_sources(srcs ${PARAM_UNPARSED_ARGUMENTS})
|
2017-02-01 00:59:46 +08:00
|
|
|
list(APPEND LLVM_LINK_COMPONENTS ${PARAM_LINK_COMPONENTS})
|
2015-03-19 00:56:24 +08:00
|
|
|
|
2017-02-01 06:12:59 +08:00
|
|
|
if(PARAM_PLUGIN)
|
|
|
|
set_property(GLOBAL APPEND PROPERTY LLDB_PLUGINS ${name})
|
|
|
|
endif()
|
|
|
|
|
2015-03-19 00:56:24 +08:00
|
|
|
if (MSVC_IDE OR XCODE)
|
|
|
|
string(REGEX MATCHALL "/[^/]+" split_path ${CMAKE_CURRENT_SOURCE_DIR})
|
|
|
|
list(GET split_path -1 dir)
|
|
|
|
file(GLOB_RECURSE headers
|
|
|
|
../../include/lldb${dir}/*.h)
|
|
|
|
set(srcs ${srcs} ${headers})
|
|
|
|
endif()
|
|
|
|
if (PARAM_MODULE)
|
|
|
|
set(libkind MODULE)
|
|
|
|
elseif (PARAM_SHARED)
|
|
|
|
set(libkind SHARED)
|
|
|
|
elseif (PARAM_OBJECT)
|
|
|
|
set(libkind OBJECT)
|
|
|
|
else ()
|
2015-06-04 11:12:37 +08:00
|
|
|
# PARAM_STATIC or library type unspecified. BUILD_SHARED_LIBS
|
|
|
|
# does not control the kind of libraries created for LLDB,
|
|
|
|
# only whether or not they link to shared/static LLVM/Clang
|
|
|
|
# libraries.
|
|
|
|
set(libkind STATIC)
|
2015-03-19 00:56:24 +08:00
|
|
|
endif()
|
|
|
|
|
|
|
|
#PIC not needed on Win
|
2017-12-08 02:57:09 +08:00
|
|
|
# FIXME: Setting CMAKE_CXX_FLAGS here is a no-op, use target_compile_options
|
|
|
|
# or omit this logic instead.
|
2016-12-15 23:00:41 +08:00
|
|
|
if (NOT WIN32)
|
2015-03-19 00:56:24 +08:00
|
|
|
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
|
|
|
|
endif()
|
|
|
|
|
|
|
|
if (PARAM_OBJECT)
|
|
|
|
add_library(${name} ${libkind} ${srcs})
|
|
|
|
else()
|
2019-01-30 23:13:16 +08:00
|
|
|
if(PARAM_ENTITLEMENTS)
|
|
|
|
set(pass_ENTITLEMENTS ENTITLEMENTS ${PARAM_ENTITLEMENTS})
|
|
|
|
endif()
|
|
|
|
|
[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_NO_INSTALL_DEFAULT_RPATH)
|
|
|
|
set(pass_NO_INSTALL_RPATH NO_INSTALL_RPATH)
|
|
|
|
endif()
|
|
|
|
|
|
|
|
llvm_add_library(${name} ${libkind} ${srcs}
|
|
|
|
LINK_LIBS ${PARAM_LINK_LIBS}
|
|
|
|
DEPENDS ${PARAM_DEPENDS}
|
2019-01-30 23:13:16 +08:00
|
|
|
${pass_ENTITLEMENTS}
|
[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
|
|
|
${pass_NO_INSTALL_RPATH}
|
|
|
|
)
|
2019-10-04 20:03:03 +08:00
|
|
|
|
|
|
|
if(CLANG_LINK_CLANG_DYLIB)
|
|
|
|
target_link_libraries(${name} PRIVATE clang-cpp)
|
|
|
|
else()
|
|
|
|
target_link_libraries(${name} PRIVATE ${PARAM_CLANG_LIBS})
|
|
|
|
endif()
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
endif()
|
2015-03-19 00:56:24 +08:00
|
|
|
|
2019-11-13 06:15:06 +08:00
|
|
|
# A target cannot be changed to a FRAMEWORK after calling install() because
|
|
|
|
# this may result in the wrong install DESTINATION. The FRAMEWORK property
|
|
|
|
# must be set earlier.
|
|
|
|
if(PARAM_FRAMEWORK)
|
|
|
|
set_target_properties(liblldb PROPERTIES FRAMEWORK ON)
|
|
|
|
endif()
|
|
|
|
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
if(PARAM_SHARED)
|
|
|
|
set(install_dest lib${LLVM_LIBDIR_SUFFIX})
|
|
|
|
if(PARAM_INSTALL_PREFIX)
|
|
|
|
set(install_dest ${PARAM_INSTALL_PREFIX})
|
|
|
|
endif()
|
|
|
|
# RUNTIME is relevant for DLL platforms, FRAMEWORK for macOS
|
|
|
|
install(TARGETS ${name} COMPONENT ${name}
|
|
|
|
RUNTIME DESTINATION bin
|
|
|
|
LIBRARY DESTINATION ${install_dest}
|
|
|
|
ARCHIVE DESTINATION ${install_dest}
|
|
|
|
FRAMEWORK DESTINATION ${install_dest})
|
|
|
|
if (NOT CMAKE_CONFIGURATION_TYPES)
|
|
|
|
add_llvm_install_targets(install-${name}
|
|
|
|
DEPENDS ${name}
|
|
|
|
COMPONENT ${name})
|
2015-03-19 00:56:24 +08:00
|
|
|
endif()
|
|
|
|
endif()
|
|
|
|
|
2016-08-20 05:00:40 +08:00
|
|
|
# Hack: only some LLDB libraries depend on the clang autogenerated headers,
|
|
|
|
# but it is simple enough to make all of LLDB depend on some of those
|
|
|
|
# headers without negatively impacting much of anything.
|
2019-03-12 23:54:35 +08:00
|
|
|
if(NOT LLDB_BUILT_STANDALONE)
|
2019-01-29 00:15:27 +08:00
|
|
|
add_dependencies(${name} clang-tablegen-targets)
|
|
|
|
endif()
|
2015-03-19 00:56:24 +08:00
|
|
|
|
2017-12-08 02:57:09 +08:00
|
|
|
# Add in any extra C++ compilation flags for this library.
|
|
|
|
target_compile_options(${name} PRIVATE ${PARAM_EXTRA_CXXFLAGS})
|
|
|
|
|
2019-05-28 17:29:05 +08:00
|
|
|
if(PARAM_PLUGIN)
|
2019-07-19 00:44:45 +08:00
|
|
|
get_property(parent_dir DIRECTORY PROPERTY PARENT_DIRECTORY)
|
|
|
|
if(EXISTS ${parent_dir})
|
|
|
|
get_filename_component(category ${parent_dir} NAME)
|
|
|
|
set_target_properties(${name} PROPERTIES FOLDER "lldb plugins/${category}")
|
|
|
|
endif()
|
2019-05-28 17:29:05 +08:00
|
|
|
else()
|
|
|
|
set_target_properties(${name} PROPERTIES FOLDER "lldb libraries")
|
|
|
|
endif()
|
2016-12-16 06:01:17 +08:00
|
|
|
endfunction(add_lldb_library)
|
2015-03-19 00:56:24 +08:00
|
|
|
|
2016-12-16 06:01:17 +08:00
|
|
|
function(add_lldb_executable name)
|
2017-02-01 00:59:46 +08:00
|
|
|
cmake_parse_arguments(ARG
|
[CMake] Revised LLDB.framework builds
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.
Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)
Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle
Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath
Reviewed By: aprantl
Subscribers: friss, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55328
llvm-svn: 350391
2019-01-04 20:46:50 +08:00
|
|
|
"GENERATE_INSTALL"
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
"INSTALL_PREFIX;ENTITLEMENTS"
|
2019-10-17 08:50:39 +08:00
|
|
|
"LINK_LIBS;CLANG_LIBS;LINK_COMPONENTS;BUILD_RPATH;INSTALL_RPATH"
|
2017-02-01 00:59:46 +08:00
|
|
|
${ARGN}
|
|
|
|
)
|
|
|
|
|
2019-01-30 23:13:16 +08:00
|
|
|
if(ARG_ENTITLEMENTS)
|
|
|
|
set(pass_ENTITLEMENTS ENTITLEMENTS ${ARG_ENTITLEMENTS})
|
|
|
|
endif()
|
|
|
|
|
[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_NO_INSTALL_DEFAULT_RPATH)
|
|
|
|
set(pass_NO_INSTALL_RPATH NO_INSTALL_RPATH)
|
|
|
|
endif()
|
|
|
|
|
2017-02-01 00:59:46 +08:00
|
|
|
list(APPEND LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
|
2019-01-30 23:13:16 +08:00
|
|
|
add_llvm_executable(${name}
|
|
|
|
${pass_ENTITLEMENTS}
|
[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
|
|
|
${pass_NO_INSTALL_RPATH}
|
2019-01-30 23:13:16 +08:00
|
|
|
${ARG_UNPARSED_ARGUMENTS}
|
[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
|
|
|
)
|
2017-02-01 00:59:46 +08:00
|
|
|
|
[CMake] Use PRIVATE in target_link_libraries for executables
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
2017-12-06 05:49:56 +08:00
|
|
|
target_link_libraries(${name} PRIVATE ${ARG_LINK_LIBS})
|
2019-10-04 20:03:03 +08:00
|
|
|
if(CLANG_LINK_CLANG_DYLIB)
|
|
|
|
target_link_libraries(${name} PRIVATE clang-cpp)
|
|
|
|
else()
|
|
|
|
target_link_libraries(${name} PRIVATE ${ARG_CLANG_LIBS})
|
|
|
|
endif()
|
[CMake] Revised LLDB.framework builds
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.
Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)
Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle
Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath
Reviewed By: aprantl
Subscribers: friss, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55328
llvm-svn: 350391
2019-01-04 20:46:50 +08:00
|
|
|
set_target_properties(${name} PROPERTIES FOLDER "lldb executables")
|
2018-06-19 02:27:16 +08:00
|
|
|
|
2019-10-17 08:50:39 +08:00
|
|
|
if (ARG_BUILD_RPATH)
|
|
|
|
set_target_properties(${name} PROPERTIES BUILD_RPATH "${ARG_BUILD_RPATH}")
|
|
|
|
endif()
|
|
|
|
|
|
|
|
if (ARG_INSTALL_RPATH)
|
|
|
|
set_target_properties(${name} PROPERTIES
|
|
|
|
BUILD_WITH_INSTALL_RPATH OFF
|
|
|
|
INSTALL_RPATH "${ARG_INSTALL_RPATH}")
|
|
|
|
endif()
|
|
|
|
|
2018-07-17 03:19:56 +08:00
|
|
|
if(ARG_GENERATE_INSTALL)
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
set(install_dest bin)
|
|
|
|
if(ARG_INSTALL_PREFIX)
|
|
|
|
set(install_dest ${ARG_INSTALL_PREFIX})
|
|
|
|
endif()
|
|
|
|
install(TARGETS ${name} COMPONENT ${name}
|
2019-10-17 08:50:39 +08:00
|
|
|
RUNTIME DESTINATION ${install_dest}
|
|
|
|
LIBRARY DESTINATION ${install_dest}
|
|
|
|
BUNDLE DESTINATION ${install_dest}
|
|
|
|
FRAMEWORK DESTINATION ${install_dest})
|
2016-12-21 00:28:18 +08:00
|
|
|
if (NOT CMAKE_CONFIGURATION_TYPES)
|
2017-12-12 08:47:07 +08:00
|
|
|
add_llvm_install_targets(install-${name}
|
2017-12-13 09:14:27 +08:00
|
|
|
DEPENDS ${name}
|
|
|
|
COMPONENT ${name})
|
2016-09-22 05:02:16 +08:00
|
|
|
endif()
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
if(APPLE AND ARG_INSTALL_PREFIX)
|
|
|
|
lldb_add_post_install_steps_darwin(${name} ${ARG_INSTALL_PREFIX})
|
|
|
|
endif()
|
2016-09-22 05:02:16 +08:00
|
|
|
endif()
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
endfunction()
|
2016-12-16 06:01:17 +08:00
|
|
|
|
2019-04-17 05:15:28 +08:00
|
|
|
|
|
|
|
macro(add_lldb_tool_subdirectory name)
|
|
|
|
add_llvm_subdirectory(LLDB TOOL ${name})
|
|
|
|
endmacro()
|
|
|
|
|
2016-12-16 06:01:17 +08:00
|
|
|
function(add_lldb_tool name)
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
cmake_parse_arguments(ARG "ADD_TO_FRAMEWORK" "" "" ${ARGN})
|
|
|
|
if(LLDB_BUILD_FRAMEWORK AND ARG_ADD_TO_FRAMEWORK)
|
|
|
|
set(subdir LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources)
|
|
|
|
add_lldb_executable(${name}
|
|
|
|
GENERATE_INSTALL
|
|
|
|
INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR}/${subdir}
|
|
|
|
${ARG_UNPARSED_ARGUMENTS}
|
|
|
|
)
|
|
|
|
lldb_add_to_buildtree_lldb_framework(${name} ${subdir})
|
|
|
|
return()
|
|
|
|
endif()
|
|
|
|
|
|
|
|
add_lldb_executable(${name} GENERATE_INSTALL ${ARG_UNPARSED_ARGUMENTS})
|
2016-12-16 06:01:17 +08:00
|
|
|
endfunction()
|
2015-10-14 22:52:15 +08:00
|
|
|
|
2019-07-11 00:00:03 +08:00
|
|
|
# The test suite relies on finding LLDB.framework binary resources in the
|
|
|
|
# build-tree. Remove them before installing to avoid collisions with their
|
|
|
|
# own install targets.
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
function(lldb_add_to_buildtree_lldb_framework name subdir)
|
2019-05-29 19:26:06 +08:00
|
|
|
# Destination for the copy in the build-tree. While the framework target may
|
|
|
|
# not exist yet, it will exist when the generator expression gets expanded.
|
2019-10-31 01:33:05 +08:00
|
|
|
set(copy_dest "${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/${subdir}/$<TARGET_FILE_NAME:${name}>")
|
2019-05-29 19:26:06 +08:00
|
|
|
|
2019-07-11 00:00:03 +08:00
|
|
|
# Copy into the given subdirectory for testing.
|
2019-05-29 19:26:06 +08:00
|
|
|
add_custom_command(TARGET ${name} POST_BUILD
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:${name}> ${copy_dest}
|
|
|
|
COMMENT "Copy ${name} to ${copy_dest}"
|
|
|
|
)
|
|
|
|
endfunction()
|
|
|
|
|
2019-07-11 00:00:03 +08:00
|
|
|
# Add extra install steps for dSYM creation and stripping for the given target.
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
function(lldb_add_post_install_steps_darwin name install_prefix)
|
|
|
|
if(NOT APPLE)
|
|
|
|
message(WARNING "Darwin-specific functionality; not currently available on non-Apple platforms.")
|
|
|
|
return()
|
|
|
|
endif()
|
|
|
|
|
|
|
|
get_target_property(output_name ${name} OUTPUT_NAME)
|
|
|
|
if(NOT output_name)
|
|
|
|
set(output_name ${name})
|
|
|
|
endif()
|
|
|
|
|
|
|
|
get_target_property(is_framework ${name} FRAMEWORK)
|
|
|
|
if(is_framework)
|
|
|
|
get_target_property(buildtree_dir ${name} LIBRARY_OUTPUT_DIRECTORY)
|
|
|
|
if(buildtree_dir)
|
|
|
|
set(bundle_subdir ${output_name}.framework/Versions/${LLDB_FRAMEWORK_VERSION}/)
|
|
|
|
else()
|
|
|
|
message(SEND_ERROR "Framework target ${name} missing property for output directory. Cannot generate post-install steps.")
|
|
|
|
return()
|
|
|
|
endif()
|
|
|
|
else()
|
|
|
|
get_target_property(target_type ${name} TYPE)
|
|
|
|
if(target_type STREQUAL "EXECUTABLE")
|
|
|
|
set(buildtree_dir ${LLVM_RUNTIME_OUTPUT_INTDIR})
|
|
|
|
else()
|
|
|
|
# Only ever install shared libraries.
|
|
|
|
set(output_name "lib${output_name}.dylib")
|
|
|
|
set(buildtree_dir ${LLVM_LIBRARY_OUTPUT_INTDIR})
|
|
|
|
endif()
|
|
|
|
endif()
|
|
|
|
|
2019-07-11 00:00:03 +08:00
|
|
|
# Generate dSYM
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
set(dsym_name ${output_name}.dSYM)
|
|
|
|
if(is_framework)
|
|
|
|
set(dsym_name ${output_name}.framework.dSYM)
|
|
|
|
endif()
|
|
|
|
if(LLDB_DEBUGINFO_INSTALL_PREFIX)
|
|
|
|
# This makes the path absolute, so we must respect DESTDIR.
|
|
|
|
set(dsym_name "\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
|
|
|
|
endif()
|
|
|
|
|
|
|
|
set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
|
|
|
|
install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" COMPONENT ${name})
|
|
|
|
install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} ${buildtree_name})"
|
|
|
|
COMPONENT ${name})
|
|
|
|
|
2019-11-05 09:00:23 +08:00
|
|
|
if(NOT LLDB_SKIP_STRIP)
|
|
|
|
# Strip distribution binary with -ST (removing debug symbol table entries and
|
|
|
|
# Swift symbols). Avoid CMAKE_INSTALL_DO_STRIP and llvm_externalize_debuginfo()
|
|
|
|
# as they can't be configured sufficiently.
|
|
|
|
set(installtree_name "\$ENV\{DESTDIR\}${install_prefix}/${bundle_subdir}${output_name}")
|
|
|
|
install(CODE "message(STATUS \"Stripping: ${installtree_name}\")" COMPONENT ${name})
|
|
|
|
install(CODE "execute_process(COMMAND xcrun strip -ST ${installtree_name})"
|
|
|
|
COMPONENT ${name})
|
|
|
|
endif()
|
[CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
2019-07-10 19:09:29 +08:00
|
|
|
endfunction()
|
|
|
|
|
2019-05-29 19:26:06 +08:00
|
|
|
# CMake's set_target_properties() doesn't allow to pass lists for RPATH
|
|
|
|
# properties directly (error: "called with incorrect number of arguments").
|
|
|
|
# Instead of defining two list variables each time, use this helper function.
|
|
|
|
function(lldb_setup_rpaths name)
|
|
|
|
cmake_parse_arguments(LIST "" "" "BUILD_RPATH;INSTALL_RPATH" ${ARGN})
|
|
|
|
set_target_properties(${name} PROPERTIES
|
|
|
|
BUILD_WITH_INSTALL_RPATH OFF
|
|
|
|
BUILD_RPATH "${LIST_BUILD_RPATH}"
|
|
|
|
INSTALL_RPATH "${LIST_INSTALL_RPATH}"
|
|
|
|
)
|
[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
|
|
|
endfunction()
|
2019-07-18 21:30:37 +08:00
|
|
|
|
|
|
|
function(lldb_find_system_debugserver path)
|
|
|
|
execute_process(COMMAND xcode-select -p
|
|
|
|
RESULT_VARIABLE exit_code
|
|
|
|
OUTPUT_VARIABLE xcode_dev_dir
|
|
|
|
ERROR_VARIABLE error_msg
|
|
|
|
OUTPUT_STRIP_TRAILING_WHITESPACE)
|
|
|
|
if(exit_code)
|
|
|
|
message(WARNING "`xcode-select -p` failed:\n${error_msg}")
|
|
|
|
else()
|
|
|
|
set(subpath "LLDB.framework/Resources/debugserver")
|
|
|
|
set(path_shared "${xcode_dev_dir}/../SharedFrameworks/${subpath}")
|
|
|
|
set(path_private "${xcode_dev_dir}/Library/PrivateFrameworks/${subpath}")
|
|
|
|
|
|
|
|
if(EXISTS ${path_shared})
|
|
|
|
set(${path} ${path_shared} PARENT_SCOPE)
|
|
|
|
elseif(EXISTS ${path_private})
|
|
|
|
set(${path} ${path_private} PARENT_SCOPE)
|
|
|
|
else()
|
|
|
|
message(WARNING "System debugserver requested, but not found. "
|
|
|
|
"Candidates don't exist: ${path_shared}\n${path_private}")
|
|
|
|
endif()
|
|
|
|
endif()
|
|
|
|
endfunction()
|
2020-03-07 09:07:23 +08:00
|
|
|
|
|
|
|
# Removes all module flags from the current CMAKE_CXX_FLAGS. Used for
|
|
|
|
# the Objective-C++ code in lldb which we don't want to build with modules.
|
|
|
|
# Reasons for this are that modules with Objective-C++ would require that
|
|
|
|
# all LLVM/Clang modules are Objective-C++ compatible (which they are likely
|
|
|
|
# not) and we would have rebuild a second set of modules just for the few
|
|
|
|
# Objective-C++ files in lldb (which slows down the build process).
|
|
|
|
macro(remove_module_flags)
|
|
|
|
string(REGEX REPLACE "-fmodules-cache-path=[^ ]+" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
|
|
|
|
string(REGEX REPLACE "-fmodules-local-submodule-visibility" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
|
|
|
|
string(REGEX REPLACE "-fmodules" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
|
|
|
|
string(REGEX REPLACE "-gmodules" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
|
|
|
|
string(REGEX REPLACE "-fcxx-modules" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
|
|
|
|
endmacro()
|