Because swift_swap_compiler_if_needed updates the compiler ID to
Clang, we need to account for it when deciding to add a dependency on
clang. Otherwise, the sourcekit build could fail due to the clang
executable not having been built there yet.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
This setting is set early in SourceKit's CMake logic to match Swift's CMake settings.
However, it was then reset back to the empty string. The CMake logic would then see that it was unset and use the host OS as the deployment target.
Thankfully, the compiled binaries have been correct without this change, but sourcekitd.framework's Info.plist when building for iOS was incorrect.
By removing the reset, the correct value propagates to the right places.
This is for <rdar://problem/85511244> and addresses <rdar://problem/68656762>.
There's no reason to use -m${platform}-version-min as of clang-11/Xcode 11. Clang is now smart enough to parse -target and provide Apple's ld with the appropriate -platform_version argument string.
Use `add_compile_options` to add new compiler options rather than
modifying `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS` which are meant to be
controlled entirely by the user.
This is needed as SwiftSyntaxParser also needs to be built with clang as
it uses blocks unconditionally. However, building with cl provides much
better diagnostics and debugging as well as a significantly faster
build (~15-20% faster) as well as a faster compiler.
SourceKit uses libdispatch for concurrency. Unfortunately, libdispatch
requires clang due to extensions. Switch to `clang-cl` or `clang` as
appropriate when building with a non-clang based host compiler.
In particular, the dependency on blocks (and certain attributes) makes
porting libdispatch to cl infeasible.
Libraries in sourcekitd depending on the external libdispatch project
appear to only depend on the *build* step, but really need the install
to happen as well since we are linking to the installed location.
Attempt to use the host compiler when building libdispatch for SourceKit. This
is needed for cross-compiling scenarios (e.g. building the Windows toolchain on
Linux). However, unfortunately, the Ubuntu 14.04 build bots are using an
ancient compiler, so we cannot use that for building libdispatch. Add a
fallback to the just built clang. Ensure that the fallback only activates when
compiling on the same host as the target.
The SourceKit component requires libdispatch and BlocksRuntime to run.
We build the libraries as part of the build and use it via imported
targets. Ensure that the dependencies get installed for use at runtime.
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.
In the case that a system update temporarily breaks the command, the output may
be empty, and this can cause CMake to fail in a weird manner. Quote the
variable to be more resilient to the transient failure.
When building libdispatch for SourceKit, only enable the swift overlay
components if the swift standard library is being built. This allows building
just the compiler and SourceKit.
The decision to whether build InProc or as an XPC service is needed for the
test tools as well. Rather than recompute it for the tests as well, hoist it to
the top level for the SourceKit project. This repairs the build of the
SourceKit tests on non-Darwin hosts.
When configuring libdispatch as part of the swift build on Linux with SourceKit
enabled, we would default to a release build. However, that results in known
leaks being reported with LSAN when building with a debug standard library.
Pass along the `LIBDISPATCH_BUILD_TYPE` into the CMake build and map that to the
CMAKE_BUILD_TYPE for the project.
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
