This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Previously, build-script-impl would set this to "" by default, resulting
in nothing being installed with --install-swift unless you explicitly
set --swift-install-components as well. Now we defer to cmake by
default.
On the cmake side, change the default value to exclude
* dev - uses a lot of disk space and usually not something you want to
install into a toolchain
* clang-resource-dir-symlink & clang-builtin-headers-in-clang-resource-dir -
these are mutually exclusive with clang-builtin-headers
* sourcekit inproc/xpc - these are currently mutually exclusive, so pick
the best one for the current platform.
* Create Swift libSyntax API
This patch is an initial implementation of the Swift libSyntax API. It
aims to provide all features of the C++ API but exposed to Swift.
It currently resides in SwiftExperimental and will likely exist in a
molten state for a while.
* Only build SwiftSyntax on macOS
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
In which case the 'SWIFT_INSTALL_[component]' will be FALSE.
This is useful to get the behavior where all components are set to install by default and exclude just a specific one.
* Ensure LLVM_CMAKE_DIR is always set so it can be used
* Use LLVM_CMAKE_DIR instead of searching the module paths
* Label parameters of cmake_parse_arguments in comments
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
The problem here is a bit complicated. The symlink_clang_headers target creates two symlinks to clang's headers, one under the build directory at lib/swift/clang, and the other under a temporary path.
The one under the temporary path is a bad symlink, and it is only created during the build so that it can be installed. It isn't actually used by the build. Ninja treats the bad symlink as a non-existing file, and since the build rule that creates it has the restat property on it this results in the commands to symlink the clang headers directory running over and over and over again during the build.
This patch prevents that by not generating the bad symlink during the build. Instead we generate it at install time using the LLVMInstallSymlink script that is vended as part of LLVM's distribution.
We also validate that each one of the given components sets are actually sets
and in addition are disjoint from each other.
In order to make sure that this is a NFC change, add all components to all 3
variables. This ensures that we preserve normal behavior of generating cmake
targets for all components and building all components by default even when
nothing is passed in to be installed.
In the next little bit I am going to be creating a more complex components
system. In order to help with this, I am renaming SwiftInstallComponents =>
SwiftComponents.cmake to reflect the broader purpose.
