[CMake] Stabilize install process for LLDB.framework

[sgraenitz]

Summary

We got used to post-build commands for copying resources into the build-tree framework. Executables were included by adding their target names to the list of LLDB_FRAMEWORK_TOOLS. Install destinations were set in add_lldb_tool(<target-name> ...).

This patch unifies these steps in lldb_add_to_framework() which:

• adds a copy to the build-tree framework for testing
• adds a cleanup step to run before install
• sets the target's destination in the install-tree

Key changes:

• LLDB_BUILD_FRAMEWORK now disables the default GENERATE_INSTALL logic
• LLDB_FRAMEWORK_TOOLS is obsolete; instead each tool calls lldb_add_to_framework() individually
• lldb_setup_framework_rpaths_in_tool() is obsolete; instead targets set them individually using lldb_setup_rpaths (old function will be removed in a separate commit to keep the diff readable)
• lldb-framework gets built by default
• the build-tree copy operation is a POST_BUILD command for the individual targets (instead of the lldb-framework target)
• while configuring the build, lldb_framework_cleanup_list_raw.txt collects <command> <expr> pairs to "strip" from the framework before install
• eventually, the final list of <command> <path> pairs is stored in lldb_framework_cleanup_list_paths.txt
• first action for install runs all the cleanup commands (see LLDBFrameworkInstall.cmake)

Test with monorepo:

$ cmake -GNinja -DCMAKE_INSTALL_PREFIX=/path/to/install/Developer/usr \
        -DLLDB_FRAMEWORK_INSTALL_DIR=/path/to/install/SharedFrameworks \
        -DLLVM_TARGETS_TO_BUILD="X86;ARM;AArch64" -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON \
        -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" \
        -DLLDB_BUILD_FRAMEWORK=ON -DLLDB_NO_INSTALL_DEFAULT_RPATH=ON ../llvm-project/llvm
$ ninja check-lldb
$ ninja install

More background:

A framework is represented by the CMake target for the shared library it ships. Installing the target copies the entire bundle from the build-tree to the install-tree. This is mostly good, because we can add additional resource files to the build-tree framework bundle and install will include them automatically. We need the additional resources in the build-tree framework to facilitate testing.

Apart from simple files, however, LLDB.framework ships executable resources that define their own install targets (for extra processing at install-time like RPATH substitution or stripping). Apparently, CMake does not provide a way to run these install targets in the course of the framework install target. Instead they run either before or after framework install. The former is problematic, because the framework install will overwrite correctly processed resource executables with their build-tree pendants. While an install-order oriented fix may sound suitable at first appearance, we should keep in mind that, formally, CMake defines an order only locally:

[install] This command generates installation rules for a project. Rules specified by calls to this command within a source directory are executed in order during installation. The order across directories is not defined.

[JDevlieghere]

How does this cleanup affect dependency tracking? Does the build dir become unusable after running ninja install?

[labath]

I'm not very familiar with frameworks and complexities involved in creating them, but the fact that we need to delete stuff from the build tree in order to install properly makes me think that there is something fishy going on. Is there no way to arrange things so that this can be avoided? For instance, what if we set the build output paths to be separate and disjoint locations for each target. Then use a separate target, or some POST_BUILD commands to copy/symlink the files to construct an build-tree framework, and have the install targets create the install-tree framework from the original build output paths?

[sgraenitz]

In D61952#1504346, @labath wrote:

I'm not very familiar with frameworks and complexities involved in creating them, but the fact that we need to delete stuff from the build tree in order to install properly makes me think that there is something fishy going on. Is there no way to arrange things so that this can be avoided?

Well, maybe there are better ways to do it, but we have a number of restrictions.

For instance, what if we set the build output paths to be separate and disjoint locations for each target. Then use a separate target, or some POST_BUILD commands to copy/symlink the files to construct an build-tree framework, and have the install targets create the install-tree framework from the original build output paths?

Ok, so you mean copying the entire framework to a staging directory, something like a "test-tree". Then we add test resources and run the test suite there. Sounds reasonable, I will investigate.
Certainly we had to consider ordering issues too, because all external headers and libraries must be copied in first, before copying to the test-tree.

In D61952#1503551, @JDevlieghere wrote:

How does this cleanup affect dependency tracking? Does the build dir become unusable after running ninja install?

Good point. Ideally we'd just copy them in again before running the test suite. Unlike I expected, this doesn't work at the moment. Maybe I should get this done first:

$ cmake -GNinja ...
$ ninja check-lldb
$ ninja install
$ ninja check-lldb

Which other test suite invocation(s) should I verify?

[sgraenitz]

Actually, why not make the copy operations PRE_BUILD actions of the test suite instead of POST_BUILD actions of their executables?

[labath]

In D61952#1504942, @sgraenitz wrote:

Actually, why not make the copy operations PRE_BUILD actions of the test suite instead of POST_BUILD actions of their executables?

Because one might want to run the lldb executable independently of the test suite?

[sgraenitz]

I thought about one more option, but I don't think it's better than the current proposal: instead of deleting the build-tree resources in the very first install step, I could install the framework manually at this point and skip its regular install target. We would loose implicit stripping and RPATH replacement for the dylib though. Should be possible to do it manually, but if it breaks, we won't notice. So, it's not quite appealing.

In D61952#1504991, @labath wrote:

Because one might want to run the lldb executable independently of the test suite?

Agreed, it would be inconvenient to have non-functional build results. The solution to the "install -> test" issue would be having both I guess.
Adding this to the current patch still sounds like the most convenient approach to me.

In D61952#1504941, @sgraenitz wrote:

In D61952#1504346, @labath wrote:

For instance, what if we set the build output paths to be separate and disjoint locations for each target. Then use a separate target, or some POST_BUILD commands to copy/symlink the files to construct an build-tree framework, and have the install targets create the install-tree framework from the original build output paths?

Ok, so you mean copying the entire framework to a staging directory, something like a "test-tree". Then we add test resources and run the test suite there. Sounds reasonable, I will investigate.

In fact, your above comment is more relevant here. I'd have to set all build-tree RPATHs to the staging framework instead of the actual target output. Sounds like a number of non-intuitive edits all over the CMake scripts..

[sgraenitz]

Yet another option: we could install the framework tools to a fake location and copy them to their final destination (overwriting their build-tree pendants) in a manual install step at the very end of the install process. The problem here is, that there may be more things in the build-tree framework than we overwrite, and thus remain in the install-tree (thinking about Swift resources in swift-lldb for example).

[labath]

Yeah, neither of the options look really appealing... Still, I can't escape the feeling that we are doing something wrong, as the installation process should not be that complicated. Or is the framework support in cmake just not good enough?

Given that Alex (I believe) is the only other major user of the framework build, I'll let you two figure out what's the best way forward here...

In D61952#1505027, @sgraenitz wrote:

The problem here is, that there may be more things in the build-tree framework than we overwrite, and thus remain in the install-tree (thinking about Swift resources in swift-lldb for example).

Why are the swift resources (whatever they are) in the build-tree framework if they should not end up being installed?

[sgraenitz]

Sure, ideally CMake defined a global install order and this order would handle overlap. I think that's unlikely to happen. It took quite some time to find and fix an overlap case downstream and I think it's worth avoiding it in general in the future. OTOH I see that the solution shouldn't be too intrusive. For the swift resources: I am not familiar with the details; all I know is that tests fail if they are missing.

[sgraenitz]

In D61952#1503551, @JDevlieghere wrote:

How does this cleanup affect dependency tracking? Does the build dir become unusable after running ninja install?

In D61952#1504942, @sgraenitz wrote:
Actually, why not make the copy operations PRE_BUILD actions of the test suite instead of POST_BUILD actions of their executables?

In D61952#1505019, @sgraenitz wrote:
The solution to the "install -> test" issue would be having both I guess.

TBH, I don't know how to accomplish this in the current state of the build system. I went through various options and didn't find a functioning one that works without, basically, turning everything upside down. We have similar functionality in lldb-framework-headers, but the appraoch only works in the directory where lldb-framework was defined. Furthermore we cannot rely on the existence of lldb-framework as lldb_add_to_framework() may be called before /lldb/source/API is processed (e.g. everything else in /lldb/source).

On one hand, the main use-case works: if the test suite succeeds then run install. And it sounds "kind of" acceptable that it fails the other way around.
On the other hand, seeing the amount of extra effort, "workaround" may be a better term to describe this change then "stabilize".

At the moment I agree, that neither of the options look really appealing. Good point to rethink the approach and find something more solid. If that fails, I might re-evaluate this one.

@xiaobai Out of interest: have you faced overwrite issues when running install and would this patch help?

[xiaobai]

In D61952#1506608, @sgraenitz wrote:

@xiaobai Out of interest: have you faced overwrite issues when running install and would this patch help?

It's been a while since I've looked at in detail but I don't remember having any issues. It's possible that I don't remember or things have changed while I didn't notice. I'll play with my build and try it out with your patch applied, and then report back.

[sgraenitz]

Ok thanks. I will be OOO next week, so no hurries.

[sgraenitz]

Closing this in favor of the reduced proposal

lldb/CMakeLists.txt

set(CMAKE_MODULE_PATH
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
   )
 
 include(LLDBStandalone)
 include(LLDBConfig)
 include(AddLLDB)
 
+if(LLDB_BUILD_FRAMEWORK)
+  # Cleanup the build-tree before installing the framework. Install actions run
+  # in configure order. We add this early, so that cleanup runs first.
+  install(SCRIPT cmake/modules/LLDBFrameworkInstall.cmake
+          CODE "lldb_framework_prepare_install()")
+endif()
+
 # Define the LLDB_CONFIGURATION_xxx matching the build type
 if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
   add_definitions( -DLLDB_CONFIGURATION_DEBUG )
 else()
   add_definitions( -DLLDB_CONFIGURATION_RELEASE )
 endif()
 
 if(APPLE)
if(APPLE)
       endif()
     endif()
   endif()
 
   if(TARGET dsymutil)
     list(APPEND LLDB_TEST_DEPS dsymutil)
   endif()
 
+  if(TARGET lldb-framework)
+    list(APPEND LLDB_TEST_DEPS lldb-framework)
+  endif()
+
   add_custom_target(lldb-test-deps)
   add_dependencies(lldb-test-deps ${LLDB_TEST_DEPS})
 
   add_subdirectory(test)
   add_subdirectory(unittests)
   add_subdirectory(lit)
   add_subdirectory(utils/lit-cpuid)
   add_subdirectory(utils/lldb-dotest)
if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
         file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
         add_custom_command(
             TARGET finish_swig
             POST_BUILD
             COMMAND ${CMAKE_COMMAND} -E copy ${PYTHON_DLL_NATIVE_PATH} ${LLDB_BIN_DIR} VERBATIM
             COMMENT "Copying Python DLL to LLDB binaries directory.")
     endif ()
 endif ()
+
+if(LLDB_BUILD_FRAMEWORK)
+  # Expand generator expressions in the list of files to be removed from the
+  # framework bundle before installation. We run this late, because it requires
+  # the respective targets to exist.
+  file(GENERATE
+    OUTPUT ${CMAKE_BINARY_DIR}/lldb_framework_cleanup_list_paths.txt
+    INPUT ${CMAKE_BINARY_DIR}/lldb_framework_cleanup_list_raw.txt
+  )
+endif()

lldb/cmake/modules/AddLLDB.cmake

else()
 
     llvm_add_library(${name} ${libkind} ${srcs}
       LINK_LIBS ${PARAM_LINK_LIBS}
       DEPENDS ${PARAM_DEPENDS}
       ${pass_ENTITLEMENTS}
       ${pass_NO_INSTALL_RPATH}
     )
 
-    if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "liblldb")
+    if (NOT LLDB_BUILD_FRAMEWORK AND (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "liblldb"))
       if (PARAM_SHARED)
-        if(${name} STREQUAL "liblldb" AND LLDB_BUILD_FRAMEWORK)
-          if(LLDB_FRAMEWORK_INSTALL_DIR)
-            set(install_dir ${LLDB_FRAMEWORK_INSTALL_DIR})
-          else()
-            set(install_dir ".")
-          endif()
-        else()
-          set(install_dir lib${LLVM_LIBDIR_SUFFIX})
-        endif()
         install(TARGETS ${name}
           COMPONENT ${name}
           RUNTIME DESTINATION bin
           LIBRARY DESTINATION ${install_dir}
           ARCHIVE DESTINATION ${install_dir})
       else()
         install(TARGETS ${name}
           COMPONENT ${name}
add_llvm_executable(${name}
     ${pass_ENTITLEMENTS}
     ${pass_NO_INSTALL_RPATH}
     ${ARG_UNPARSED_ARGUMENTS}
   )
 
   target_link_libraries(${name} PRIVATE ${ARG_LINK_LIBS})
   set_target_properties(${name} PROPERTIES FOLDER "lldb executables")
 
-  if(ARG_GENERATE_INSTALL)
+  if(ARG_GENERATE_INSTALL AND NOT LLDB_BUILD_FRAMEWORK)
     install(TARGETS ${name}
             COMPONENT ${name}
             RUNTIME DESTINATION bin)
     if (NOT CMAKE_CONFIGURATION_TYPES)
       add_llvm_install_targets(install-${name}
                                DEPENDS ${name}
                                COMPONENT ${name})
     endif()
function(lldb_setup_framework_rpaths_in_tool name)
   set_target_properties(${name} PROPERTIES
     BUILD_WITH_INSTALL_RPATH OFF
     BUILD_RPATH "${framework_target_dir}"
     INSTALL_RPATH "${rpaths_install_tree}"
   )
 
   add_dependencies(${name} lldb-framework)
 endfunction()
+
+# Unified handling for executable LLDB.framework resources. Given the name of an
+# executable target, this function will: set the target's destination in the
+# install-tree, copy it to the framework in the build-tree and remove the copy
+# before installing the framework. The target's default build directory remains
+# unchanged.
+function(lldb_add_to_framework name)
+  # Same subdirectory in both cases, build-tree and install-tree.
+  set(subdir "LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources")
+
+  # Destination for the copy in the build-tree. While the framework may not exist
+  # yet, it will exist when the generator expression gets expanded.
+  set(copy_dest "$<TARGET_FILE_DIR:liblldb>/../../../${subdir}")
+
+  # Copy into the framework's Resources directory for testing.
+  add_custom_command(TARGET ${name} POST_BUILD
+    COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:${name}> ${copy_dest}
+    COMMENT "Copy ${name} to ${copy_dest}"
+  )
+
+  # Before installing, remove the copy from the build-tree framework, so it
+  # won't be installed together with the framework bundle and accidentally
+  # replace the target's already installed binary.
+  lldb_add_framework_cleanup_entry("remove ${copy_dest}/$<TARGET_FILE_NAME:${name}>")
+
+  # Install into the framework bundle in the install-tree.
+  install(TARGETS ${name} COMPONENT ${name}
+    DESTINATION ${LLDB_FRAMEWORK_INSTALL_DIR}/${subdir}
+  )
+endfunction()
+
+# Add an entry to the list of things we clean up before running install.
+# Generator expressions are expanded to actual paths at the end of the
+# configuration process. Entries consist of a command and a path,
+#  e.g.: remove /path/to/file
+#        remove_directory /path/to/directory
+function(lldb_add_framework_cleanup_entry entry)
+  file(APPEND ${CMAKE_BINARY_DIR}/lldb_framework_cleanup_list_raw.txt "${entry}\n")
+endfunction()
+
+# 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}"
+  )
+endfunction()

lldb/cmake/modules/LLDBConfig.cmake

if(LLDB_BUILD_FRAMEWORK)
   # CMake < 3.8 did not have the BUILD_RPATH target property
   if(CMAKE_VERSION VERSION_LESS 3.8)
     message(FATAL_ERROR "LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.8")
   endif()
 
   set(LLDB_FRAMEWORK_VERSION A CACHE STRING "LLDB.framework version (default is A)")
   set(LLDB_FRAMEWORK_BUILD_DIR bin CACHE STRING "Output directory for LLDB.framework")
   set(LLDB_FRAMEWORK_INSTALL_DIR Library/Frameworks CACHE STRING "Install directory for LLDB.framework")
-  set(LLDB_FRAMEWORK_TOOLS darwin-debug;debugserver;lldb-argdumper;lldb-server CACHE STRING
-      "List of tools to include in LLDB.framework/Resources")
 
   # Set designated directory for all dSYMs. Essentially, this emits the
   # framework's dSYM outside of the framework directory.
   if(LLVM_EXTERNALIZE_DEBUGINFO)
     set(LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin CACHE STRING
         "Directory to emit dSYM files stripped from executables and libraries (Darwin Only)")
   endif()
 endif()

lldb/cmake/modules/LLDBFramework.cmake

set_target_properties(liblldb PROPERTIES
   SOVERSION "1.0.0"
 
   MACOSX_FRAMEWORK_IDENTIFIER com.apple.LLDB.framework
   MACOSX_FRAMEWORK_BUNDLE_VERSION ${LLDB_VERSION}
   MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${LLDB_VERSION}
   MACOSX_FRAMEWORK_INFO_PLIST ${LLDB_SOURCE_DIR}/resources/LLDB-Info.plist.in
 )
 
+# Install in framework location
+install(TARGETS liblldb COMPONENT liblldb
+  FRAMEWORK DESTINATION ${LLDB_FRAMEWORK_INSTALL_DIR}
+)
+
 # Affects the layout of the framework bundle (default is macOS layout).
 if(IOS)
   set_target_properties(liblldb PROPERTIES
     XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET "${IPHONEOS_DEPLOYMENT_TARGET}")
 else()
   set_target_properties(liblldb PROPERTIES
     XCODE_ATTRIBUTE_MACOSX_DEPLOYMENT_TARGET "${MACOSX_DEPLOYMENT_TARGET}")
 endif()
 
 # Target to capture extra steps for a fully functional framework bundle.
-add_custom_target(lldb-framework)
+add_custom_target(lldb-framework ALL)
 add_dependencies(lldb-framework liblldb)
 
-# Dependencies are defined once tools are added (see AddLLDB.cmake)
-if(LLDB_FRAMEWORK_TOOLS)
-  message(STATUS "LLDB.framework: adding tools ${LLDB_FRAMEWORK_TOOLS}")
-  foreach(tool ${LLDB_FRAMEWORK_TOOLS})
-    add_custom_command(TARGET lldb-framework POST_BUILD
-      COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:${tool}> $<TARGET_FILE_DIR:liblldb>/Resources
-      COMMENT "LLDB.framework: copy additional tool ${tool}"
-    )
-  endforeach()
-else()
-  message(WARNING "LLDB.framework: no additional tools configured (set via LLDB_FRAMEWORK_TOOLS)")
-endif()
-
 # Apart from this one, CMake creates all required symlinks in the framework bundle.
 add_custom_command(TARGET lldb-framework POST_BUILD
   COMMAND ${CMAKE_COMMAND} -E create_symlink
           Versions/Current/Headers
           ${framework_target_dir}/LLDB.framework/Headers
   COMMENT "LLDB.framework: create Headers symlink"
 )
 

lldb/cmake/modules/LLDBFrameworkInstall.cmake

+# If LLDB_BUILD_FRAMEWORK is enabled, this CMake script is included from cmake_install.cmake
+
+# Runs as first action of the install target, removing all files and directories
+# that were copied into the framework for testing.
+function(lldb_framework_prepare_install)
+  # Framework tools must install themselves, instead of being copied over inside
+  # the framework bundle. Affected files were added via lldb_add_to_framework()
+  # and logged in a text file in the build directory. Read all entries now.
+  file(STRINGS ${CMAKE_BINARY_DIR}/lldb_framework_cleanup_list_paths.txt cleanup_commands)
+
+  # Multiple cmake invocations may have added duplicates.
+  list(REMOVE_DUPLICATES cleanup_commands)
+
+  # Dump and delete each file/folder.
+  foreach(cmd ${cleanup_commands})
+    message(STATUS "Cleanup: ${cmd}")
+    separate_arguments(cmd)
+    execute_process(COMMAND ${CMAKE_COMMAND} -E ${cmd})
+  endforeach()
+endfunction()

lldb/tools/argdumper/CMakeLists.txt

 add_lldb_tool(lldb-argdumper
   argdumper.cpp
 
   LINK_LIBS
     lldbUtility
   )
+
+if(LLDB_BUILD_FRAMEWORK)
+  lldb_add_to_framework(lldb-argdumper)
+endif()

lldb/tools/darwin-debug/CMakeLists.txt

 add_lldb_tool(darwin-debug
   darwin-debug.cpp
   )
+
+if(LLDB_BUILD_FRAMEWORK)
+  lldb_add_to_framework(darwin-debug)
+endif()

lldb/tools/debugserver/source/CMakeLists.txt

add_lldb_tool(debugserver
 
     LINK_LIBS
       lldbDebugserverCommon
 
     ENTITLEMENTS
       ${entitlements}
     )
 
+  if(LLDB_BUILD_FRAMEWORK)
+    lldb_add_to_framework(debugserver)
+  endif()
+
   if(IOS)
     set_property(TARGET lldbDebugserverCommon APPEND PROPERTY COMPILE_DEFINITIONS
       WITH_LOCKDOWN
       WITH_FBS
       WITH_BKS
       )
     set_property(TARGET debugserver APPEND PROPERTY COMPILE_DEFINITIONS
       WITH_LOCKDOWN

lldb/tools/driver/CMakeLists.txt

 endif()
 
 add_dependencies(lldb
   LLDBOptionsTableGen
   ${tablegen_deps}
 )
 
 if(LLDB_BUILD_FRAMEWORK)
-  lldb_setup_framework_rpaths_in_tool(lldb)
+  # Framework builds disable default install targets
+  install(TARGETS lldb COMPONENT lldb DESTINATION bin)
+
+  # In the build-tree, we know the exact path to the framework directory.
+  # The installed framework can be in different locations.
+  get_target_property(framework_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
+  lldb_setup_rpaths(lldb
+    BUILD_RPATH
+      "${framework_build_dir}"
+    INSTALL_RPATH
+      "@loader_path/../../../SharedFrameworks"
+      "@loader_path/../../System/Library/PrivateFrameworks"
+      "@loader_path/../../Library/PrivateFrameworks"
+  )
 endif()

lldb/tools/lldb-mi/CMakeLists.txt

add_lldb_tool(lldb-mi
   LINK_LIBS
     liblldb
     ${host_lib}
     ${extra_libs}
 
   LINK_COMPONENTS
     Support
   )
-
-if(LLDB_BUILD_FRAMEWORK)
-  lldb_setup_framework_rpaths_in_tool(lldb-mi)
-endif()

lldb/tools/lldb-server/CMakeLists.txt

LINK_LIBS
       lldbPluginInstructionMIPS64
       ${LLDB_SYSTEM_LIBS}
 
     LINK_COMPONENTS
       Support
 )
 
 target_link_libraries(lldb-server PRIVATE ${LLDB_SYSTEM_LIBS})
+
+if(LLDB_BUILD_FRAMEWORK)
+  lldb_add_to_framework(lldb-server)
+endif()

lldb/tools/lldb-vscode/CMakeLists.txt

add_lldb_tool(lldb-vscode
   LINK_LIBS
     liblldb
     ${host_lib}
     ${extra_libs}
 
   LINK_COMPONENTS
     Support
   )
-
-if(LLDB_BUILD_FRAMEWORK)
-  lldb_setup_framework_rpaths_in_tool(lldb-vscode)
-endif()