Extract the ExternalProject handling for libdispatch needed to build
SourceKit on Linux into a separate CMake list. This will allow us to
pull in a dependency on Foundation as well to allow building SwiftSyntax
on Linux which requires Foundation. Foundation has a dependency on
libdispatch requiring that the external project handling is centralised.
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
During a parallel build, this was noticed:
<unknown>:0: error: missing required module 'SwiftShims'
Ensure that we have a dependency on the SwiftShims target for
libdispatch.
This pays a small penalty in build times by invoking an extra call to
ninja. However, unless there is a change in libdispatch, no actions
will be taken other than ensuring that it is up-to-date. Should ensure
that the buildbots switching between builds DTRT.
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.
Currently, SourceKit's CMake functions all use DEPENDS to specify
libraries the targets will link with. This is confusing as it doesn't
behave the same way that add_swift behaves, and implies that
dependencies are created when there aren't.
The Linux build has a dependency on the libdispatch library,
which is needed by the various native libraries for sourcekitd.
On macOS, the dependency for libdispatch is satisfied directly through
the base OS, but on Linux no such dependency exists.
Modify this so that if the SourceKit library is built, and the
libdispatch library is already present, then we shell out to make
the libdispatch binary project when the SourceKit is built.
Issue: SR-1676
The Linux build has a dependency on the libdispatch library,
which is needed by the various native libraries for sourcekitd.
On macOS, the dependency for libdispatch is satisfied directly through
the base OS, but on Linux no such dependency exists.
Modify this so that if the SourceKit library is built, and the
libdispatch library is already present, then we shell out to make
the libdispatch binary project when the SourceKit is built.
Issue: SR-1676
The Linux build has a dependency on the libdispatch library,
which is needed by the various native libraries for sourcekitd.
On macOS, the dependency for libdispatch is satisfied directly through
the base OS, but on Linux no such dependency exists.
Modify this so that if the SourceKit library is built, and the
libdispatch library is already present, then we shell out to make
the libdispatch binary project when the SourceKit is built.
Issue: SR-1676
Reset Darwin specific CMake variables to match the correct
SDK and architecture. This is needed when cross compiling, or we'll end up with
conflicting SDK and architectures.
Remove unused variable SOURCEKIT_GLOBAL_DEPLOYMENT_TARGET_FLAGS.
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
SourceKit makes heavy use of blocks. In order to port SourceKit to Linux,
we either need to rewrite much of it to use function pointers, or we must
require a blocks runtime. This commit requires a blocks runtime, but only
when SourceKit is being built. Currently, SourceKit is not built on Linux,
so this should not affect anyone.