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
- 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
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.