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.
add_sourcekit_default_compiler_flags was invoking
_add_variant_link_flags and getting link flags but not actually using
the link_libraries or library_search_directories. In android builds,
this means that the correct libc++ is not being linked against.
`-fblocks` is a core driver option now, so it can be used with both the GCC
style driver as well as the cl style driver. Simplify the logic for the
handling of this option.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Ensure that we install the client header for the InProc sourcekitd. This is
needed to actually make it usable. With this, it is now possible to develop
against SourceKit on Linux and Windows.
Set all the target properties in a single shot. This avoids the multiple string
parsing within CMake. Although this makes no noticable differnce, it is
slightly more efficient and also colocates all the target properties.
SourceKit's build is now ammenable to building for Windows. Generalize the path
to enable building it for Windows as well as Linux. The libdispatch build for
the compiler is needed for all non-Darwin targets currently.
Not all targets (CMAKE_SYSTEM_NAME) use `lib` and `.a` for the static library
name. Adjust the name properly for the host that we are building for. This
repairs the build when performing a cross-compile from Linux to Windows.
This is useful because the embedded platforms may have the same toolchain version but they contain
different stdlibs. We need to make sure the XPC service name is unique between them, otherwise we may load
and use the incorrect toolchain service.
rdar://39077520
Avoid overwriting the `swiftCore` target in the SourceKit build.
Instead, link to the explicit variant of the swiftCore. This tracks the
dependency better and enables multiple parallel cross-compilations of
the stdlib.
Implicitly link against swiftCore when linking against libdispatch.
Remove the extraneous link against the Blocks runtime on Linux. The
`add_sourcekit_executable` call already handles this. Ensure that we
enable the swift SDK overlay for libdispatch by sending it the path to
the swift compiler.
This is a NFC change that makes it easier to read SourceKit's main
CMakeLists.txt file since you only see "actions" rather than also this huge list
of helper routines.
