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=install/Developer/usr \
-DLLVM_TARGETS_TO_BUILD="X86;ARM;AArch64" -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON \
-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](https://cmake.org/cmake/help/v3.4/command/install.html):
[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.